1.1 Where Does a Query Go?

Suppose a client sends SELECT * FROM users WHERE id = 1. The path that single line travels before coming back as a result row is longer than you might expect. 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?: the backend decides which processing path the client message 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.

Chapter 1.1, the one you're reading, splits into three sections.

• 1.1.1 Life of a Query: compresses all five stages into a single diagram. The map for the rest of the 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.

After this chapter, it should be clear how the backend's main loop receives a client message and dispatches it to the right function.