Horton

Re: Set query_id for query contained in utility statement

Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>

View thread View on postgr.es
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-21T08:35:17Z
Lists: pgsql-hackers

Attachments

Hi,

On Fri, Oct 18, 2024 at 8:27 AM Michael Paquier <michael@paquier.xyz> wrote:
> Beginning with the beginning of this patch series.
>
> +SELECT toplevel, calls, query FROM pg_stat_statements
> +  ORDER BY toplevel desc, query COLLATE "C";
>
> In v8-0001, for the tests that want to track the queries showing up,
> could it be better to adjust the ORDER BY to be (query, toplevel,
> calls), making the query string first?  This way, it is possible to
> see which are the doublons of queries showing up for toplevel as true
> and false depending on the utility.

I've updated 0001 to only use ORDER BY query. The query strings are
not exact doublons, as the nested statement has the additional ending
';' due to using the whole string instead of just the RawStmt. Thus,
the other sort expressions will never be used since there's no
equality. There's also the possibility of breaking down each statement
in individual blocks, with pgss reset and fetch for each one. However,
I feel it's gonna add a lot of noise in the test file.

Commits

  1. Set query ID for inner queries of CREATE TABLE AS and DECLARE

  2. Track more precisely query locations for nested statements

  3. pg_stat_statements: Add tests for nested queries with level tracking

  4. Fix race condition in COMMIT PREPARED causing orphaned 2PC files