postgres /

PostgreSQL

Live map
Snapshotmaster · 3d00537

A server backend parses each SQL statement, chooses a costed plan, executes access methods against buffered pages, and protects writes with WAL.

Click a building or route
Choose a path

SQL becomes a Query and Plan, whose executor pulls visible tuples through access methods and shared buffers.

System map8 components · 9 connections
130%
PostgreSQL: SQL through planning, execution, storage, and WAL architectureThe query journey loops through access methods and the buffer cache; the write journey branches from heap changes into WAL and replication.SQL text and parser se…typed Query tree, rang…planned statement with…snapshot, tuple slot, …relation fork and bloc…buffer handle, page by…tuple slot after MVCC …Postmasterand backendParser andanalyzerPlanner andoptimizerExecutorHeap andindex accessSharedbuffer cacheWrite-aheadlogStandbyreplicas
Connections
BuildingsEntryServiceComputeStorageRuntimeToolingExternal

Terms, in plain English

Backend processA PostgreSQL server process that handles one client session and executes its statements.

How to study this repo

  1. 1
    Follow SQL into a plan

    Trace postgres.c, parser.c, and planner.c; note the representation produced at each boundary.

  2. 2
    Pull one tuple

    Read execMain.c, nodeSeqscan.c, heapam.c, and bufmgr.c to see the executor's pull-based storage path.

  3. 3
    Protect one write

    Connect heap WAL insertion, xlog.c durability rules, and walsender.c streaming to a standby.