PostgreSQL Select Source Code Analysis

PostgreSQL Select Source Code Analysis

This time sequence diagram is relatively large, but it roughly describes the general process for PostgreSQL to process simple SQL statements.

The client initiates an SQL statement. After receiving the Statement by the PG server process backend, exec_simple_query () code is executed. All subsequent method calls are directly or indirectly initiated by the exec_simple_query () function.

It is divided into the following processes: pg_parse_query ()-> pg_analyze_and_rewrite ()-> pg_plan_queries ()->... ExecutePlan ()... -> Pg_report_stat ().

Pg_parse_query

Only raw parse tree is generated, which does not involve semantic check. It only performs a syntax scan and is a Bison parser.

Pg_analyze_and_rewrite

This module performs Semantic Analysis and accesses the image in the database, and requires a lock. This process Splits a simple select statement into multiple parts and converts the parse tree into a query tree. For example, convert the entire select statement to the from part,

Where condition, group by, order by, and having. It is a very important part of any database that requires operations.

Pg_plan_queries

In this step, an execution plan is generated based on the preceding query tree. This part of the core code is the Query Optimizer of PG in planner. c. The possible value of different paths will be calculated based on the statistical information of tables and indexes, and the author will be selected.

I will write an article later. I will talk about this topic, that is, "The Cost-based Optimizer principle of PG ".

ExecutePlan

Execute the plan, which traverses each node to complete. Finally, return the query result to the client.

Pg_report_stat

Send the statistics to collector. For example, how many times a table or index is scanned and how many records are returned. If it is a DML statement, the number of records to be deleted will be increased. The original information is table-based and then summarized to the database or instance level.

This is very important for health checks or monitoring PG performance.

From the sequence diagram below, we can see that the tasks of each source code file are very clear.

Ipvs. c: backend process, which is responsible for mixing and scheduling. It is the server process corresponding to the client. Because PG is in the C/S architecture, after each client connects to PG, postmaster will fork a backend process to interact with it.

Xact. c: transaction-related operations. The status mark of the transaction, isolation level, and whether there are nested transactions.

Utility. c: the type of a statement or command, including delete, insert, update, select, explain, create, and alter.

ExecMain. c: the entry to the total scheduling of execution statements.

Pgstat. c: Collects and displays database statistics.

Portalmem. c: Memory application and release during statement execution. In PG, a special name is called portal, which is equivalent to workspace.

------------------------------------ Lili split line ------------------------------------

Install PostgreSQL 6.3 on yum in CentOS 9.3

PostgreSQL cache details

Compiling PostgreSQL on Windows

Configuration and installation of LAPP (Linux + Apache + PostgreSQL + PHP) Environment in Ubuntu

Install and configure phppgAdmin on Ubuntu

Install PostgreSQL9.3 on CentOS

Configure a Streaming Replication cluster in PostgreSQL

How to install PostgreSQL 7/6 and phpPgAdmin in CentOS 5/6. 4

------------------------------------ Lili split line ------------------------------------

PostgreSQL details: click here
PostgreSQL: click here

This article permanently updates the link address: