Where is the qualification par in the Query Tree
This refers to /doc/src/sgml/html/querytree.html, where one mentions a qualification part in the Query Tree. While reading the Query node (parsenode.h) and output from the log with debug_print_parse = on, I cannot see either this part. Is it gone in profit of join tree ?
Re: Where is the qualification par in the Query Tree
=?UTF-8?Q?Marc_Recht=c3=a9?= writes: > This refers to /doc/src/sgml/html/querytree.html, where one mentions a > qualification part in the Query Tree. While reading the Query node > (parsenode.h) and output from the log with debug_print_parse = on, I > cannot see either this part. Is it gone in profit of join tree ? As noted near the bottom of that documentation page: It turns out to be convenient to store the top-level WHERE expression as a qualification attached to the top-level join-tree item, too. So really the join tree represents both the FROM and WHERE clauses of a SELECT. IOW, Query.jointree->quals. regards, tom lane
Re: Backend Flowchart / Developer doc
On Thu, Apr 16, 2020 at 11:17:29AM -0400, Alvaro Herrera wrote: > On 2020-Apr-15, Marc Rechté wrote: > > > Hello, > > > > Don't know if this the correct list to submit this issue. > > > > On the https://www.postgresql.org/developer/backend/, it mentions a > > Query.qual field which does not exist in the Query structure. > > I think that diagram (and the accompanying wiki page) requires a *lot* > of more significant updating than just that field. It is wildly > outdated. I developed the attached patch to fix the items I saw needed updating. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/templates/pages/developer/backend.html b/templates/pages/developer/backend.html index ab7e5d6..7337a07 100644 --- a/templates/pages/developer/backend.html +++ b/templates/pages/developer/backend.html @@ -56,7 +56,7 @@ or https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h";>SelectStmt. The statement is then identified as complex (SELECT / INSERT / -UPDATE / DELETE) or simple, e.g CREATE USER, ANALYZE, +UPDATE / DELETE) or simple, e.g CREATE ROLE, ANALYZE, etc. Simple utility commands that do not require the executor are processed by statement-specific functions in the https://wiki.postgresql.org/wiki/Backend_flowchart#commands";>commands module. Complex statements require more handling. @@ -64,11 +64,12 @@ Complex statements require more handling. The parser takes a complex query, and creates a https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h";>Query structure that contains all the elements used by complex queries. -Query.qual holds the WHERE clause qualification, which is filled +Query.jointree holds the FROM and WHERE clauses, which is filled in by https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c";>transformFromClause() and href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c";>transformWhereClause(). Each table referenced in the query is represented by a https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h";>RangeTableEntry, +href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/parsenodes.h";>RangeTblEntry, and they are linked together to form the range table of the query, which is generated by https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/parse_clause.c";>transformFromClause(). @@ -95,8 +96,8 @@ system. The https://wiki.postgresql.org/wiki/Backend_flowchart#optimizer_path";>optimizer uses the Query structure to determine the best table join order and join -type of each table in the RangeTable, using Query.qual(WHERE -clause) to consider optimal index usage. The FROM +and WHERE clauses) to consider optimal index usage. The https://wiki.postgresql.org/wiki/Backend_flowchart#optimizer_path";>path module then generates an optimal https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/nodes/plannodes.h";>Plan,
Missing description about the performance impact of archive_timeout
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/runtime-config-wal.html Description: The PostgreSQL manual contains the following paragraph https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT about the archive_timeout: > archive_timeout (integer) > Note that archived files that are closed early due to a forced switch are still the same length as completely full files. Therefore, it is unwise to use a very short archive_timeout — it will bloat your archive storage. archive_timeout settings of a minute or so are usually reasonable. The description mentions that a short archive_timeout would cause storage cost but miss the potential performance loss of a short archive_timeout. Also, while it seems setting the archive_mode to off will disable the effect of this parameter, it is not the case. Therefore, I think it would be great to elaborate this description further: > "A short archive_timeout would also lead to performance penalties if the wal_sync_method is open_sync. Turning the archive_mode to off would not mitigate the performance loss" Rationale: I test the archive_timeout on PostgreSQL 11 with a small table (50MB) on Ubuntu 18.04. I run the sysbench with an insert-intensive workload. I tweak the configuration parameters below: - wal_sync_method = open_sync - archive_mode = on - archive_command = 'cp %p /path-to-data/pg_archive/%f' - archive_timeout = 1/5/10/30/60 When the archive_timeout is 1, the average latency is 35.61 ms. When the archive_timeout is 5, the average latency is 8.05ms. When the archive_timeout is 10, the average latency is 6.8 ms. When the archive_timeout is 30, the average latency is 5.3 ms. When the archive_timeout is 60, the average latency is 4.77 ms. When the archive_timeout is 0, the average latency is 4.71 ms. The result shows that if the archive_timeout is short and the wal_sync_method is open_sync, the system will suffer significant performance degradation. The performance regression will not be mitigated by closing the archive_mode. If I change the wal_sync_method to other options, the average latency doesn't change significantly when I change the archive_timeout. Some guidance books like PostgreSQL 9 Administration Cookbook suggests a relative short value like 30 seconds. It seems that some users in practice will use a low timeout value like 5 seconds: e.g., https://dba.stackexchange.com/questions/194629/file-creation-dates-of-archived-wal-files-not-in-line-with-archive-timeout-in-po, perhaps because they are not worried much about the storage cost. Thus, I think it would be helpful to include the caveat about the performance impact in the documentation as well.
Re: An XSLT example script
On 2020-04-14 10:03, Jürgen Purtz wrote: The example "XSLT Stylesheet for Converting SQL/XML Output to HTML" is tagged as , but it isn't a figure, it's an example script. It's not an example, it's an actual script that you are supposed to use. The PDF output contains lists for examples, figures and tables and shows it in the wrong list. We should change the tagging. Why is it wrong to make this a figure? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: An XSLT example script
On Tue, Apr 21, 2020 at 08:10:09PM +0200, Peter Eisentraut wrote: > On 2020-04-14 10:03, Jürgen Purtz wrote: > > The example "XSLT Stylesheet for Converting SQL/XML Output to HTML" is > > tagged as , but it isn't a figure, it's an example script. > > It's not an example, it's an actual script that you are supposed to use. Uh, the text said "example", and all the other figures we had used SVG files, so it didn't see to match our other markup. > > The > > PDF output contains lists for examples, figures and tables and shows it > > in the wrong list. We should change the tagging. > > Why is it wrong to make this a figure? I thought figure was just images. Was figure really right, or something else? This is the only script we use? programlisting maybe? -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: An XSLT example script
On 21.04.20 20:10, Peter Eisentraut wrote: On 2020-04-14 10:03, Jürgen Purtz wrote: The example "XSLT Stylesheet for Converting SQL/XML Output to HTML" is tagged as , but it isn't a figure, it's an example script. It's not an example, it's an actual script that you are supposed to use. The PDF output contains lists for examples, figures and tables and shows it in the wrong list. We should change the tagging. Why is it wrong to make this a figure? Sorry, I don't understand. Do we speak about the same position in the documentation? https://www.postgresql.org/docs/12/functions-xml.html#XSLT-XML-HTML Scripts usually are tagged as "screen", "programmlisting", "example", "synopsis/function" (for functions) - but never as a figure. The introductory text explicitly says "As an example ...". Therefor "example" seems to be appropriate. IMO "programmlisting" is also possible. And: there is no single graphical element like a line, a circle, a color, or an UML-symbol. -- Jürgen Purtz
