On Mon, Aug 26, 2024 at 5:26 AM jian he <jian.universal...@gmail.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.
v3-0001-Set-query_id-for-queries-contained-in-utility-sta.patch
Description: Binary data
