Several issues observed on Postgres 14.1
NikolayS opened this issue · 2 comments
Thanks for the great extension.
Tried it on PG 14.1, and had the following issues:
- TIMING and BUFFERS are not working – tried to set it everywhere, on both sides, globally – doesn't matter, I don't get those numbers in the
pg_query_stateoutput leader_pidis not working as described in README. Maybe there is something that has changed in recent postgres versions (whenleader_pidappeared inpg_stat_activity?), but for parallelized queries,pg_query_statealways returns a single entry for me -- parallel workers are not displayed. I ended up using this workaround:select pid, leader_pid, (select plan from pg_query_state(pid)) from pg_stat_activity where :PID in (pid, leader_pid) \watch .5
Hi! Thank you for your reporting.
- I would like to clarify - are you receiving a notification
WARNING: timing/buffers statistics disabledor is there no warning, the parameters are enabled, but the statistics are not displayed?
And also what results does thepython3 tests/pg_qs_test_runner.pycommand produce? - leader_pid in pg_query_state and in pg_stat_activity is one and the same. I checked it on postgresql 14.1.
I changed your query and received the correct answer. The proposed query will not produce an answer, at least because for the parent query pg_query_state() will produce a plan not in one line, but in several (added limit 1).
select pid, leader_pid, (select plan from pg_query_state(pg_stat_activity.pid) limit 1)
from pg_stat_activity where leader_pid = 82491 or pid = 82491;
-[ RECORD 1 ]---------------------------------------------------------------------------------------------------------------------
pid | 86745
leader_pid | 82491
plan | Partial Aggregate (Current loop: actual rows=0, loop number=1) +
| -> Parallel Hash Join (Current loop: actual rows=4482143, loop number=1) +
| Hash Cond: (ticket_flights.ticket_no = boarding_passes.ticket_no) +
| -> Parallel Seq Scan on ticket_flights (Current loop: actual rows=2812080, loop number=1) +
| -> Parallel Hash (Current loop: actual rows=2666556, loop number=1) +
| Buckets: 131072 Batches: 128 Memory Usage: 3968kB +
| -> Parallel Seq Scan on boarding_passes (Current loop: actual rows=2666556, loop number=1)
-[ RECORD 2 ]---------------------------------------------------------------------------------------------------------------------
pid | 86746
leader_pid | 82491
plan | Partial Aggregate (Current loop: actual rows=0, loop number=1) +
| -> Parallel Hash Join (Current loop: actual rows=4439745, loop number=1) +
| Hash Cond: (ticket_flights.ticket_no = boarding_passes.ticket_no) +
| -> Parallel Seq Scan on ticket_flights (Current loop: actual rows=2789880, loop number=1) +
| -> Parallel Hash (Current loop: actual rows=2696472, loop number=1) +
| Buckets: 131072 Batches: 128 Memory Usage: 4000kB +
| -> Parallel Seq Scan on boarding_passes (Current loop: actual rows=2696472, loop number=1)
-[ RECORD 3 ]---------------------------------------------------------------------------------------------------------------------
pid | 82491
leader_pid |
plan | Finalize Aggregate (Current loop: actual rows=0, loop number=1) +
| -> Gather (Current loop: actual rows=0, loop number=1) +
| Workers Planned: 2 +
| Workers Launched: 2 +
| -> Partial Aggregate (Current loop: actual rows=0, loop number=1) +
| -> Parallel Hash Join (Current loop: actual rows=4499590, loop number=1) +
| Hash Cond: (ticket_flights.ticket_no = boarding_passes.ticket_no) +
| -> Parallel Seq Scan on ticket_flights (Current loop: actual rows=2789892, loop number=1) +
| -> Parallel Hash (Current loop: actual rows=2562784, loop number=1) +
| Buckets: 131072 Batches: 128 Memory Usage: 4000kB +
| -> Parallel Seq Scan on boarding_passes (Current loop: actual rows=2562784, loop number=1)
It seems the problem may be in the wrong location for setting the guc-variables.
An important point: in order for a pg_query_state() launched in the backend with pid 111 to be able to read statistics on the time/buffers of a query launched in backend 222, the variables must be set in backend 222:
backend 222:
SET pg_query_state.enable_timing = on;
-- than run some query
backend 111:
SELECT * FROM pg_query_state(222, true, true, true, true, true);
-- the result contains time statistics
Or, to avoid possible misunderstandings, you can set these variables in the configuration file postgresql.conf (but it is worth remembering that this may increase overhead, since statistics will be collected for all backends, and not selected ones).
I think I should add this information to the README.md.
I hope this answer solves your problem, so I'm closing the issue. If it turns out that the problem was not in the settings, please feel free to create a new issue. Good luck.