Overview
Chapter 2에서 우리는 백엔드 프로세스에 대해 설명하였습니다. 백엔드 프로세스는 자신이 담당하는 커넥션으로부터 들어온 쿼리를 처리하는 역할을 수행합니다. 본 문서에는 조금 더 깊게 들어가서 백엔드 프로세스가 쿼리를 처리(Query Processing)하는 쿼리를 처리하는 과정을 소개하겠습니다.
백엔드 프로세스에서 쿼리를 처리하는 각 과정은 다음과 같습니다. 각 과정을 하나 씩 설명드리겠습니다.
Parser
대부분의 데이터베이스와 마찬가지로 PostgreSQL은 SQL 문법으로 작성된 문자열(평문) 형태의 쿼리를 입력으로 받습니다. Parser는 입력받은 쿼리의 문법(Syntax)를 검증하는 작업을 수행합니다. 또한 문법 구조를 바탕으로 Parse Tree를 생성하는 역할을 수행합니다.
The parser has to check the query string (which arrives as plain text) for valid syntax. The parser stage creates a parse tree using only fixed rules about the syntactic structure of SQL.
– PostgreSQL 공식 문서 –
문법 검증을 수행한다는 것은 SELECT, FROM, WHERE 등이 구문이 적절한 위치에 쓰여졌는지, 쉼표가 적절히 쓰여졌는지 만을 판단한다는 의미입니다. 따라서, Parser에서는 실제 테이블, 컬럼의 존재 여부와 같은 Semantic 검증은 수행하지 않습니다. 해당 작업은 Analyzer에서 수행합니다.
Parser에서 수행하는 단계를 정확히 이해하기 위하여 Parse Tree라는 개념에 대해서 알 필요가 있습니다. Parse Tree는 Parse Node라고 불리는 구조체들로 이루어진 Tree입니다. Parse Node는 해당 구문의 성격(INSERT, SELECT 등)에 따라 상이한 내용을 담고 있습니다. Parse Node 구조체의 정의는 다음에서 살펴볼 수 있습니다.(”Stmt”를 접미사로 가지는 구조체들)
Reference.
https://www.postgresql.org/docs/current/parser-stage.html#id-1.10.3.6.3
Analyzer
Analyzer는 Parser에서 생성한 Parse Tree를 입력 받아 Query Tree를 생성합니다. 상술하였듯 Parse Tree는 문법만 고려되어 있고 실제 테이블, 컬럼과 같은 의미론적인(Semantic) 내용은 포함하고 있지 않습니다. Analyzer에서는 Parse Tree에서 언급하는 테이블, 컬럼, 연산자의 유효성 등에 대한 Semantic 검증을 System Catalog 조회를 통해 수행하고, 해당 내용을 추가하여 Query Tree를 생성합니다. 즉, Query Tree는 Parse Tree와 달리 테이블, 컬럼을 참조하기 위한 정보를 포함하고 있다는 점에서 차이를 보입니다.
the transformation process takes the tree handed back by the parser as input and does the semantic interpretation needed to understand which tables, functions, and operators are referenced by the query. The data structure that is built to represent this information is called the query tree.
– PostgreSQL 공식 문서 –
Query Tree의 루트 노드는 다음에 Query라는 이름의 구조체로 구현되어 있습니다. (*Parse Tree의 구조체들과 같은 곳에 구현되어 있으니 유의바랍니다.)
다음 그림은 이전 문단에서 언급했던 Parse Tree를 Query Tree로 변경한 예시입니다. 해당 그림에서 각 서브 트리의 내용이 다른 노드를 참조하여 보강된 것을 확인할 수 있으며, relid (Relation Id) 등 실제 대상 오브젝트를 찾아가기 위한 정보 또한 추가 된 것을 확인할 수 있습니다.
Reference.
https://www.postgresql.org/docs/current/parser-stage.html#id-1.10.3.6.3
https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c
Rewriter
Analyzer에서 생성된 Query Tree는 Planner에 전달되기 전, Rewrite 과정을 거치게 됩니다. Rewriter는 사용자가 Rule System에 저장한 규칙을 기반으로 Query Tree를 수정합니다.
It modifies queries to take rules into consideration, and then passes the modified query to the query planner for planning and execution.
– PostgreSQL 공식 문서 –
* Rule System은 테이블의 INSERT, UPDATE, DELETE 등에 대해 사용자가 지정한 작업을 대신 수행할 수 있게 하는 기능입니다. 자세한 내용은 해당 문서를 참고하길 바랍니다.
Reference.
https://www.postgresql.org/docs/current/rule-system.html
https://www.postgresql.org/docs/current/rules.html
https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c
Planner / Optimizer
Analyzer와 Rewriter를 거친 Query Tree는 Planner에 전달됩니다. Planner는 쿼리가 요구하는 데이터의 명세인 Query Tree를 기반으로 해당 데이터를 찾고, 가공하기 위한 실행 계획 즉, Plan Tree를 생성합니다.
The task of the planner/optimizer is to create an optimal execution plan
– PostgreSQL 공식 문서 –
하나의 쿼리에서는 수 많은 조합의 실행 계획이 만들어질 수 있습니다. 따라서, 대부분의 데이터베이스에서는 각 계획의 비용(Cost)를 계산하여 가장 효율적인 실행 계획을 선택합니다. PostgreSQL은 이를 위해 Cost-based optimization 방식을 사용합니다. (Tibero, Oracle의 방식과 다르므로 혼동하지 않도록 참고 바랍니다.)
Reference.
https://www.postgresql.org/docs/current/planner-optimizer.html
Executor
Executor는 Planner/Optimizer로부터 받은 Plan Tree 형태의 Plan을 반복적으로 처리하여 필요한 Row들을 받아옵니다. 즉, 입력된 Plan Tree의 각 Plan Node에 따라 순차적으로 적절한 알고리즘을 수행하여 데이터를 가공합니다.
The executor takes the plan created by the planner/optimizer and recursively processes it to extract the required set of rows.
– PostgreSQL 공식 문서 –
지금까지 PostgreSQL의 쿼리 엔진_ Overview 에 관해 알아보았습니다
‘PostgreSQL의 쿼리 엔진_ Optimizer’편을 바로 이어서 확인해보세요!
