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.

1. Backend entry and dispatch. The backend receives the message from the client and decides which processing path it should follow.
2. Parser and Analyzer. The SQL text is parsed, and the catalog is consulted to give it meaning.
3. Rewriter. The RULE system expands views, injects RLS policies, and otherwise transforms the query tree.
4. Planner. Using a cost model, it explores possible execution paths and picks the best one.
5. Executor. It walks the chosen plan, pulling tuples up and sending them to the client.

Chapter 1 of this book unfolds this pipeline one chapter at a time. Chapter 1.1, the first one, covers stage 1: the entry point. It has 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.