After fixing the problem with utility statements, this whole block:
do $$
declare
n integer:= 1;
begin
loop
PERFORM a,b,c,d FROM t1, t2, t3, t4
WHERE t1.a = t2.b AND t3.c = t4.d ORDER BY a;
exit when n = 1000;
n := n + 1;
end loop;
end $$;
Is only processed once, as those are nested statements, in order to
match the 1000 statements the GUC pg_stat_monitor.track must be set to
'all' and then back to the default of 'top' when done testing it.
We are concerned with finished queries in pg_stat_monitor, so state and
state_code columns were removed from the pg_stat_monitor_view as we only
list finished queries on it.
Removed state regression as it is not necessary anymore.
Also, this allowed us to remove the call to pgss_store on ExecutorStart,
which just updated query state to EXEC, thus saving some CPU.
The issue is that between changing GUC "track" from track='top' to
track='all' the queries are executing using previous state of
track='top', to fix that we sleep 1 second after calling
pg_reload_conf() to ensure that queries will run with new settings.
cmd_type: Added missing DROP TABLE t2;
guc: Adjusted to match the updated settings view, which now display
boolean values as 'yes' and 'no', also added the 'options' column
to the output.
guc_1: Handle PostgreSQL versions <= 12 which don't have the
track_planning feature.
rows.out: Added missing DROP TABLE t2. Also removed the line 'ERROR:
relation "t2" already exists' since we fixed the problem in
cmd_type regression.
top_query: Handling both track = 'top' and track = 'all' cases.
top_query_1: On PostgreSQL >= 14 the sub query from the procedure is
stored as (select $1 + $2), whereas on PG <= 13 it is
stored as SELECT (select $1 + $2).
Diego Fronza
Ibrar Ahmed
Naeem Akhter
Mikhail Samoylov