Re: Set query_id for query contained in utility statement

On Mon, Aug 26, 2024 at 5:26 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> queryid | left
> | plans | calls | rows
> ----------------------+--------------------------------------------------------------+-------+-------+------
> 2800308901962295548 | EXPLAIN (verbose) create table test_t as
> select 1; | 2 | 2 | 0
> 2093602470903273926 | EXPLAIN (verbose) create table test_t as
> select $1 | 0 | 2 | 0
>
> "EXPLAIN (verbose) create table test_t as select 1;" called twice,
> is that what we expect?

pg_stat_statements reports nested queries and toplevel queries
separately. You can check with the toplevel column.
2800308901962295548 is the nested ctas part while 2093602470903273926
is the top explain utility statement (which explain why there's 0
plans since it's an utility statement). Since the explain ctas query
was called twice, it will be reported as 2 toplevel queries and 2
nested queries.

> should first row, the normalized query becomes
> EXPLAIN (verbose) create table test_t as select $1;

Good point, the issue in this case was the nested query was stored by
pg_stat_statements during the ExecutorEnd hook. This hook doesn't have
the jstate and parseState at that point so pg_stat_statements can't
normalize the query.

I've modified the patch to fix this. Instead of just jumbling the
query in ExplainQuery, I've moved jumbling in ExplainOneUtility which
already has specific code to handle ctas and dcs. Calling the post
parse hook here allows pg_stat_statements to store the normalized
version of the query for this queryid and nesting level.