Query execution is the step that happens after the optimizer has chosen a plan: the database engine actually carries that plan out and produces rows. The plan is a tree of operators - sequential scans, index lookups, joins, sorts, and aggregations - and the executor walks that tree to extract the answer. The PostgreSQL documentation describes it precisely: “the executor takes the plan created by the planner/optimizer and recursively processes it to extract the required set of rows. This is essentially a demand-pull pipeline mechanism.”
Demand-pull means rows are produced on request rather than all at once. The top of the plan asks its child operators for the next row, those children ask their own children, and so on down to the leaves where data is actually read. This pipelining lets the engine begin returning results without first materializing every intermediate result in memory, and it lets operators like joins and sorts compose cleanly into a single tree.
The leaf operators are where the plan touches storage, and this is where indexes matter. A query that filters on an indexed column can use an index scan instead of reading the whole table; as the PostgreSQL documentation notes, with an index the system “might only have to walk a few levels deep into a search tree” rather than scanning every row. Whether the executor uses an index scan or a sequential scan is decided by the optimizer, but the executor is what runs it.
Different operators carry different costs: a hash join builds a hash table in memory, a sort may spill to disk if the data is large, and an aggregation accumulates state as rows flow through it. Understanding the operator tree is the practical key to performance tuning, which is why most databases expose it. In PostgreSQL the EXPLAIN command prints exactly this tree of operators so engineers can see how a query will be executed.