Re: Set query_id for query contained in utility statement
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-18T06:21:03Z
Lists: pgsql-hackers
On Thu, Oct 17, 2024 at 09:21:11AM +0200, Anthonin Bonnefoy wrote: > I'm not sure about this approach. It moves the responsibility of > tracking the location and length from the nested statement to the top > level statement. > - The location you added in ExplainStmt and CopyStmt has a different > meaning from all others and tracks the nested location and not the > location of the statement itself. This creates some inconsistencies. > - The work will need to be done for all statements with nested > queries: Prepare, Create table as, Declare Cursor, Materialised View. > Whereas by tracking the location of PreparableStatements, there's no > need for additional logic. For example, v8 0002 fixes the existing > behaviour for Prepare statements thanks to SelectStmt's modifications. Hmm. And isn't tracking this information at only the top-level going to be a problem when dealing with multiple levels of nesting, when for example these involve pl/sql or pl/pgSQL functions? How would this work if we're dealing with multiple levels of Nodes? -- Michael
Commits
-
Set query ID for inner queries of CREATE TABLE AS and DECLARE
- 6b652e6ce85a 18.0 landed
-
Track more precisely query locations for nested statements
- 499edb09741b 18.0 landed
-
pg_stat_statements: Add tests for nested queries with level tracking
- 45e0ba30fc40 18.0 landed
-
Fix race condition in COMMIT PREPARED causing orphaned 2PC files
- cf4401fe6cf5 18.0 cited