Checkpointing marks a point in the recovery process where the system flushes all dirty pages to disk and records that state. By writing updated pages from memory to disk and logging this event, the database creates a known-good starting point for crash recovery. When the system restarts, recovery uses the most recent checkpoint plus the log to redo actions from that point and to undo any transactions that didn’t commit before the crash. The recovery log itself is the record of changes used during recovery, but it is not the moment updates are written to disk. A commit signals that a transaction’s results are durable, and rollback undoes uncommitted work; neither inherently defines the disk-write checkpoint. Thus, this term correctly identifies the moment in the recovery process when disk writes occur.

An index is a data structure that helps the database locate rows quickly by providing fast lookups on one or more columns. It works like a separate map that stores the indexed column values together with pointers to the actual rows, so the system can jump directly to the relevant data instead of scanning every row in a large table. This accelerates data search and retrieval, especially for queries in WHERE clauses, joins, or sorts on big relations. Keep in mind that indexes add some overhead for writes and extra storage, and they don’t by themselves enforce uniqueness or referential integrity (those are handled by constraints and keys), nor do they define how data is structured across tables, which is what normalization is about.

A commit finalizes a transaction and makes its changes durable. When you commit, the database records all the operations of that transaction in the persistent log and ensures those changes are written to durable storage. This guarantees that after a crash, the committed updates survive and are visible to other transactions. The idea is that a commit moves changes from being provisional to permanently stored on disk. The other options miss this durability aspect or describe rollback behavior, which is not what a commit does.

In query optimization, the optimizer assigns a numeric estimate of the work required to run a plan, called the query cost. This cost reflects expected resource use—primarily I/O and CPU, and sometimes memory—based on statistics and a cost model. Plans with lower estimated costs are preferred because they are expected to execute more efficiently, so the optimizer can compare options and pick the cheapest one. The recovery log is about durability and crash recovery, not about planning or comparing query plans. The broader process is query optimization itself, not the single metric used to evaluate plans. Operational information isn’t the standard term for the plan-cost measure either.