| |
The client initiates the SQL statement, and the PG server process backend receives the statement and begins executing the exec_simple_query () code. Behind all method calls are exec_simple_query () function directly or indirectly initiated.
Generally divided into the following process: pg_parse_query () -> pg_analyze_and_rewrite () -> pg_plan_queries () -> ... ExecutePlan () ... -> pg_report_stat ().
Pg_parse_query
But simply generate raw parse tree, which does not involve semantic checks. Just do a grammar scan that is a Bison parser.
Pg_analyze_and_rewrite
This will be a semantic analysis, will visit the database of objects, the need to hold locks. This process splits a simple select statement into multiple parts, transforming the parse tree into a query tree. Such as the entire select statement into: from part,
Where condition part, group by part, order by part and having part and so on. Is the need for any database operation, and a very important part.
Pg_plan_queries
In this session, will be based on the query tree above to generate the implementation plan. This part of the core code in planner.c, the PG Query Optimizer. Will be based on the table and the index of statistical information to calculate the possible cost of different paths, and finally select the best.
Here will not start, the back will write an article, specifically about this piece, the "PG Cost-based Optimizer principle."
ExecutePlan
Execute plan, which iterates through each node so that it completes. Finally, the query results returned to the client.
Pg_report_stat
The statistics are sent to the collector. Such as how many times the table and index have been scanned, how many records have been returned, and so on. If the DML statement, there will be additions and deletions in addition to change the number of records of statistical information. The original information is in the form of a table, which is later aggregated to the library level or the instance level.
This is important for health checks or for monitoring PG performance.
From the timing diagram below, it can be seen that the task of each source file is very clear.
Postgres.c: for the backend process, responsible for miscellaneous and scheduling, and the client is the corresponding server process. Because the PG is C / S architecture, each client to connect to the PG, postmaster will fork out a backend process to interact with.
Xact.c: is a transaction-related operation. The status flag of the transaction, the isolation level, whether there are nested transactions, and so on.
Utility.c: statement or command type, including delete, insert, update, select, explain, create, alter and so on.
ExecMain.c: is the total schedule entry for the execution statement.
Pgstat.c: responsible for database statistics collection and display.
Portalmem.c: responsible for the implementation of the statement, the memory application and release. PG, specifically take a name called portal, the equivalent of workspace. |
|
|
|