Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2ZEW-00018f-24 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Jan 2021 12:38:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l2ZEU-00063X-UO for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Jan 2021 12:38:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2ZEU-00063Q-MJ for pgsql-hackers@lists.postgresql.org; Thu, 21 Jan 2021 12:38:38 +0000 Received: from mout.kundenserver.de ([212.227.126.187]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2ZES-0004MV-5A for pgsql-hackers@lists.postgresql.org; Thu, 21 Jan 2021 12:38:38 +0000 Received: from [192.168.178.34] ([77.190.19.4]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MuF4v-1ls3mz29mP-00uWyc; Thu, 21 Jan 2021 13:38:28 +0100 Subject: Re: Additional Chapter for Tutorial - arch-dev.sgml To: Heikki Linnakangas Cc: Erik Rijkers , "David G. Johnston" , PostgreSQL Hackers , Justin Pryzby References: <13c65997-9502-7671-1a7b-50e5d5093514@purtz.de> <93fd8e15-8639-23c8-c7c4-d4cfca323189@purtz.de> <32c7ebc0-f69f-8a77-c397-8fcb9139d8d3@purtz.de> <779bb812-5238-f78b-2782-b1d990f952e3@purtz.de> <7a081d6c-e288-615c-f32c-839fb27366ed@purtz.de> <759f7a615736d8066b3441571d371c68@xs4all.nl> <99f58c4752e9984ffe38a4343fed3837@xs4all.nl> <1bfb1ae4-6f5b-bff4-15a8-a768e0ddd450@purtz.de> From: =?UTF-8?Q?J=c3=bcrgen_Purtz?= Message-ID: <67d7240f-8596-83fc-5e15-af06c128a0f5@purtz.de> Date: Thu, 21 Jan 2021 13:38:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------92C8480107FCFEFCA645B849" Content-Language: en-US X-Provags-ID: V03:K1:bRqQseLp6vSFa4fwWvtE9uG/pNtMF3joxsgW8VvgPTd6Pi0dtky 5ipHQfyE27e89jdgI9E648lPbsZ5iYk+U1/DqTk96DNmehlWd7eSNBOnrrJgl305qhcbykw a/Ou8sQSP3Xm7QBwkRIcHia0pTMkngL+nVUbl9ev2EkPDNBr/oERibjbuhT1jkjZB6UrKE2 WV7HTNmJ8WnQukp1bittQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tyW7T0BMw3k=:jWSd3WeLS3gzDTQbE4bn6G AVLH5jJgMkSrSWnst/k86DA1fHESk+YwMv/2MtJbi2BTh5Uxjztn7N/dzTxWDCumWAZ7iKD4V +D85E/ZPeOHCS+za6uxJ73T31z3V9DphXWFeT4g5aYnRT+QCbShMkCFU6kR0giRmVJSQVtMtS Ep40wf96MAR7SapbF1lf3ob7JvyQT5KG6IoZW0YagAewbaPVZXm+ERbfPmFFhWIJtuwptSSSv hcfCcT8Q7qEbr50Q8onf/okvoqgwejsHfuENKz6covLZnUkyd/JZGzBvQ7iezSmAPNxjFsYhF HOgi0+O+Ao4s4RJkGjbf9rKB49aQmOQWJGL8KyCvOirqdGpr01HgRhWnxtJ/P9UB2aCQNtUxW W09Ny1GcejDP3yFqSoi9jsGwCtJ96IYBfRKeFRsgYldS3E0TiFJFg15k8n18M List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------92C8480107FCFEFCA645B849 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 18.01.21 15:13, Heikki Linnakangas wrote: > On 20/11/2020 23:52, Erik Rijkers wrote: >> (smallish) Changes to arch-dev.sgml > > This looks good to me. One little complaint: > >> @@ -125,7 +122,7 @@ >>      use a supervisor process (also >>      master process) that spawns a new >>      server process every time a connection is requested. This >> supervisor >> -    process is called postgres and listens at a >> +    process is called postgres (formerly >> 'postmaster') and listens at a >>      specified TCP/IP port for incoming connections. Whenever a request >>      for a connection is detected the postgres >>      process spawns a new server process. The server tasks > > I believe we still call it the postmaster process. We renamed the > binary a long time ago (commit 5266f221a2), and the above text was > changed as part of that commit. I think that was a mistake, and this > should say simply: > > ... This supervisor process is called postmaster > and ... > > like it did before we renamed the binary. > > Barring objections, I'll commit this with that change (as attached). > > - Heikki Some additional changes in 51.2:  - smaller number of different terms  - aligning with Glossary  - active voice instead of passive voice  - commas --- J. Purtz --------------92C8480107FCFEFCA645B849 Content-Type: text/x-patch; charset=UTF-8; name="arch-dev.sgml.20210121.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arch-dev.sgml.20210121.diff" diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml index ade0ad97d8..7ced927c9d 100644 --- a/doc/src/sgml/arch-dev.sgml +++ b/doc/src/sgml/arch-dev.sgml @@ -7,7 +7,7 @@ Author This chapter originated as part of - , Stefan Simkovics' + Stefan Simkovics' Master's Thesis prepared at Vienna University of Technology under the direction of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr. @@ -17,10 +17,7 @@ This chapter gives an overview of the internal structure of the backend of PostgreSQL. After having read the following sections you should have an idea of how a query - is processed. This chapter does not aim to provide a detailed - description of the internal operation of - PostgreSQL, as such a document would be - very extensive. Rather, this chapter is intended to help the reader + is processed. This chapter is intended to help the reader understand the general sequence of operations that occur within the backend from the point at which a query is received, to the point at which the results are returned to the client. @@ -30,8 +27,8 @@ The Path of a Query - Here we give a short overview of the stages a query has to pass in - order to obtain a result. + Here we give a short overview of the stages a query has to pass + to obtain a result. @@ -117,21 +114,28 @@ How Connections Are Established - PostgreSQL is implemented using a - simple process per user client/server model. In this model - there is one client process connected to - exactly one server process. As we do not + PostgreSQL implements a + process per user client/server model. + In this model, every + client process + connects to exactly one + backend process. + As we do not know ahead of time how many connections will be made, we have to - use a supervisor process (also - master process) that spawns a new - server process every time a connection is requested. This supervisor - process is called postgres and listens at a - specified TCP/IP port for incoming connections. Whenever a request - for a connection is detected the postgres - process spawns a new server process. The server tasks - communicate with each other using semaphores and - shared memory to ensure data integrity - throughout concurrent data access. + use a supervisor process + that spawns a new + backend process every time a connection is requested. This supervisor + process is called + postmaster + and listens at a + specified TCP/IP port for incoming connections. Whenever he detects + a request for a connection, he spawns a new backend process. + Those backend processes communicate with each other and with other + processes of the + instance + using semaphores and + shared memory + to ensure data integrity throughout concurrent data access. @@ -144,11 +148,11 @@ - Once a connection is established the client process can send a query - to the backend (server). The query is transmitted using plain text, - i.e., there is no parsing done in the frontend (client). The - server parses the query, creates an execution plan, - executes the plan and returns the retrieved rows to the client + Once a connection is established, the client process can send a query + to his backend process. The query is transmitted using plain text, + i.e., there is no parsing done in the client. The backend + process parses the query, creates an execution plan, + executes the plan, and returns the retrieved rows to the client by transmitting them over the established connection. @@ -230,7 +234,7 @@ A detailed description of bison or the grammar rules given in gram.y would be - beyond the scope of this paper. There are many books and + beyond the scope of this manual. There are many books and documents dealing with flex and bison. You should be familiar with bison before you start to study the @@ -343,8 +347,8 @@ In some situations, examining each possible way in which a query - can be executed would take an excessive amount of time and memory - space. In particular, this occurs when executing queries + can be executed would take an excessive amount of time and memory. + In particular, this occurs when executing queries involving large numbers of join operations. In order to determine a reasonable (not necessarily optimal) query plan in a reasonable amount of time, PostgreSQL uses a Genetic @@ -411,7 +415,7 @@ merge join: Each relation is sorted on the join attributes before the join starts. Then the two relations are scanned in parallel, and matching rows are combined to form - join rows. This kind of join is more + join rows. This kind of join is attractive because each relation has to be scanned only once. The required sorting might be achieved either by an explicit sort step, or by scanning the relation in the proper order using an @@ -442,7 +446,7 @@ If the query uses fewer than relations, a near-exhaustive search is conducted to find the best join sequence. The planner preferentially considers joins between any - two relations for which there exist a corresponding join clause in the + two relations for which there exists a corresponding join clause in the WHERE qualification (i.e., for which a restriction like where rel1.attr1=rel2.attr2 exists). Join pairs with no join clause are considered only when there --------------92C8480107FCFEFCA645B849--