1.1 Where Does a Query Go?

Suppose a client sends a single line, SELECT * FROM users WHERE id = 1. Before that line becomes a result row and comes back, inside the PostgreSQL backend that SQL goes through a five-stage pipeline. The five stages are exactly the five chapters of Chapter 1.

• 1.1 Where Does a Query Go?: decides which processing path the message sent by the client should follow.
• 1.2 Parser and Analyzer: How SQL Gets Its Meaning: the SQL text is parsed, and the catalog is consulted to give it meaning.
• 1.3 Rewriter: How a Query is Rewritten: the RULE system expands views, injects RLS policies, and otherwise transforms the query tree.
• 1.4 Planner: Which Path to Take: a cost model explores possible execution paths and picks the best one.
• 1.5 Executor: How Results Come Back: the chosen plan is walked, pulling tuples up and sending them to the client.

Section 1.1, the one you're reading now, proceeds in this order.

• 1.1.1 Life of a Query: compresses all five stages into a single diagram. The map for the whole book.
• 1.1.2 Simple vs Extended: looks at the semantic difference between the two protocols.
• 1.1.3 Optimizable vs Utility: shows how SELECT/INSERT/... and CREATE/VACUUM/... take different paths.

Which function the backend's main loop dispatches a client message to is exactly what decides which processing path that SQL takes.