Re: Set query_id for query contained in utility statement

On Fri, Oct 04, 2024 at 08:16:00PM +0800, jian he wrote:
> about v5 0001
> select_with_parens:
> '(' select_no_parens ')' { $$ = $2; }
> | '(' select_with_parens ')' { $$ = $2; }
> ;
>
>
> toplevel | calls | query
> ----------+-------+-------------------------------------------------------
> t | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
> t | 0 | SELECT toplevel, calls, query FROM pg_stat_statements+
> | | ORDER BY query COLLATE "C", toplevel
> t | 1 | explain (select $1)
> f | 1 | select $1);
>
> query "select $1);" looks weird. not sure how to improve it,
> or this should be the expected behavior?

GOod point, this is confusing. The point is that having only
stmt_location is not enough to detect where the element in the query
you want to track is because it only points at its start location in
the full query string. In an ideal world, what we should have is its
start and end, pass it down to pgss_store(), and store only this
subquery between the start and end positions in the stats entry.
Making that right through the parser may be challenging, though.

This concept is something that's perhaps larger than this thread? I
think that we want the same kind of thing for values in IN() and ANY()
clauses, where we want to track an area for a single normalization
parameter, perhaps with a separate node_attr. I am not sure if using
the same trackers would make sense, so I am just waving hands a bit
here, but the concepts required are quite close.

Saying that, a patch set implemented this way would ensure a strict
1:1 mapping between a query ID and the internal query in these EXPLAIN
and CREATE commands, which would be good.

The first step should be IMO to expand the tests of pgss and track all
the behaviors we have historically in the tree about all that. Then,
it becomes much easier to track how much we want to tweak them
depending on if pgss.track is set to "top" or "all", and easier to see
how a behavior changes when manipulating the parse node structures
with location data.
--
Michael