|
7 | 7 | <title>Author</title> |
8 | 8 | <para> |
9 | 9 | This chapter originated as part of |
10 | | - <xref linkend="sim98"/>, Stefan Simkovics' |
| 10 | + <xref linkend="sim98"/> Stefan Simkovics' |
11 | 11 | Master's Thesis prepared at Vienna University of Technology under the direction |
12 | 12 | of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr. |
13 | 13 | </para> |
|
17 | 17 | This chapter gives an overview of the internal structure of the |
18 | 18 | backend of <productname>PostgreSQL</productname>. After having |
19 | 19 | read the following sections you should have an idea of how a query |
20 | | - is processed. This chapter does not aim to provide a detailed |
21 | | - description of the internal operation of |
22 | | - <productname>PostgreSQL</productname>, as such a document would be |
23 | | - very extensive. Rather, this chapter is intended to help the reader |
| 20 | + is processed. This chapter is intended to help the reader |
24 | 21 | understand the general sequence of operations that occur within the |
25 | 22 | backend from the point at which a query is received, to the point |
26 | 23 | at which the results are returned to the client. |
|
30 | 27 | <title>The Path of a Query</title> |
31 | 28 |
|
32 | 29 | <para> |
33 | | - Here we give a short overview of the stages a query has to pass in |
34 | | - order to obtain a result. |
| 30 | + Here we give a short overview of the stages a query has to pass |
| 31 | + to obtain a result. |
35 | 32 | </para> |
36 | 33 |
|
37 | 34 | <procedure> |
|
125 | 122 | use a <firstterm>supervisor process</firstterm> (also |
126 | 123 | <firstterm>master process</firstterm>) that spawns a new |
127 | 124 | server process every time a connection is requested. This supervisor |
128 | | - process is called <literal>postgres</literal> and listens at a |
| 125 | + process is called <literal>postmaster</literal> and listens at a |
129 | 126 | specified TCP/IP port for incoming connections. Whenever a request |
130 | | - for a connection is detected the <literal>postgres</literal> |
131 | | - process spawns a new server process. The server tasks |
| 127 | + for a connection is detected the <literal>postmaster</literal> |
| 128 | + process spawns a new server process. The server processes |
132 | 129 | communicate with each other using <firstterm>semaphores</firstterm> and |
133 | 130 | <firstterm>shared memory</firstterm> to ensure data integrity |
134 | 131 | throughout concurrent data access. |
|
230 | 227 | <para> |
231 | 228 | A detailed description of <application>bison</application> or |
232 | 229 | the grammar rules given in <filename>gram.y</filename> would be |
233 | | - beyond the scope of this paper. There are many books and |
| 230 | + beyond the scope of this manual. There are many books and |
234 | 231 | documents dealing with <application>flex</application> and |
235 | 232 | <application>bison</application>. You should be familiar with |
236 | 233 | <application>bison</application> before you start to study the |
|
343 | 340 | <note> |
344 | 341 | <para> |
345 | 342 | In some situations, examining each possible way in which a query |
346 | | - can be executed would take an excessive amount of time and memory |
347 | | - space. In particular, this occurs when executing queries |
| 343 | + can be executed would take an excessive amount of time and memory. |
| 344 | + In particular, this occurs when executing queries |
348 | 345 | involving large numbers of join operations. In order to determine |
349 | 346 | a reasonable (not necessarily optimal) query plan in a reasonable amount |
350 | 347 | of time, <productname>PostgreSQL</productname> uses a <firstterm>Genetic |
|
411 | 408 | <firstterm>merge join</firstterm>: Each relation is sorted on the join |
412 | 409 | attributes before the join starts. Then the two relations are |
413 | 410 | scanned in parallel, and matching rows are combined to form |
414 | | - join rows. This kind of join is more |
| 411 | + join rows. This kind of join is |
415 | 412 | attractive because each relation has to be scanned only once. |
416 | 413 | The required sorting might be achieved either by an explicit sort |
417 | 414 | step, or by scanning the relation in the proper order using an |
|
442 | 439 | If the query uses fewer than <xref linkend="guc-geqo-threshold"/> |
443 | 440 | relations, a near-exhaustive search is conducted to find the best |
444 | 441 | join sequence. The planner preferentially considers joins between any |
445 | | - two relations for which there exist a corresponding join clause in the |
| 442 | + two relations for which there exists a corresponding join clause in the |
446 | 443 | <literal>WHERE</literal> qualification (i.e., for |
447 | 444 | which a restriction like <literal>where rel1.attr1=rel2.attr2</literal> |
448 | 445 | exists). Join pairs with no join clause are considered only when there |
|
0 commit comments