# PostgreSQL Backend Flowchart

## by Bruce Momjian

Queries come into the backend via data packets coming in through TCP/IP and Unix Domain sockets. They are loaded into a string, and passed to the parser, where the lexical scanner, scan.l, breaks the query up into tokens(words). The parser uses gram.y and the tokens to identify the query type, and load the proper query-type-specific structure, like CreateStmt or SelectStmt.

The query is then identified as a Utility function or a more complex query. Utility queries are processed by a query-type-specific function in commands. Complex queries, like SELECT, UPDATE, and DELETE require much more handling.

The parser takes the complex queries, and creates a Query structure that contains all the elements used by complex queries. Query.qual holds the WHERE clause qualification, which is filled in by transformWhereClause(). Each table is represented by a RangeTableEntry, and they are linked together to form the range table for the query, and is generated by makeRangeTable(). Query.rtable holds the queries range table.

Certain queries, like SELECT, return columns of data. Other queries, like INSERT and UPDATE, specify the columns modified by the query. These columns references are converted to Resdom entries, which are linked together to make up the target list of the query. The target list is stored in Query.targetList, and is generated by transformTargetList().

Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are also stored in their own fields.

The next step is for the Query to be modified by any VIEWS or RULES that may apply to the query. This is performed by the rewrite system.

The optimizer takes the Query structure, and generates an optimal Plan containing primitive operations to be performed by the executor to complete the query. The path module determines the table join order and join type of each of the tables in the RangeTable, using Query.qual(WHERE clause) to consider optimal index usage.

The Plan is then passed to the executor for execution, and the result is returned to the client.

There are many other modules that support this basic functionality. They can be accessed by clicking on the flowchart.

Another area of interest is the shared memory area, containing table data/index blocks, locks, and backend information:

- ShmemIndex - contains an index of all other shared memory structures, allowing quick lookup of other structure locations in shared memory
- Buffer Descriptors - control header for shared memory buffer block
- Buffer Blocks - block of table/index data shared by all backends
- Shared Buf Lookup Table - lookup to see if a requested buffer is already in the shared memory area
- LockTable - lock table structure, specifiying table, lock types, and backends holding or waiting on lock
- LockTable (lock hash) - lookup of LockTable structures using table name
- LockTable (xid hash) - lookup of LockTable structures using transaction id
- Proc Header - information about each backend, including locks held/waiting, indexed by process id

Each structure is created by calling ShmemInitStruct().

Click on an item to see more detail or click here to see the full index.