| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel vacuum: I/O timings in the log leave out the parallel workers |
| Date: | 2026-09-29 06:30:33 |
| Message-ID: | CAGRkXqRGZxmWrwuL1GjkM7Sa_DYzXeEfHg-iJv53zqetEOTwJw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> So I'm inclined to backpatch it to 17. Thoughts?
+1 for 17. From 17 on, pgstat_count_io_op_time() feeds pgStatBlockReadTime
and the BufferUsage fields from the same io_time for the same objects, so
without workers the log only changes by the rounding. 16 is different, as
you said.
I ran Bharath's reproducer and compared the log line with pg_stat_io for the
same VACUUM. On master the log said
I/O timings: read: 200.596 ms, write: 200.286 ms
while pg_stat_io had
read ms write ms
leader 213.442 213.006
workers 61.415 127.415
So the workers are missing, and the log is short even of the leader's own
time, which is the microsecond rounding Bharath mentioned.
With the patch the log matched leader plus workers within 0.3 ms.
Thanks,
Shihao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-09-29 06:49:25 | Re: Add returns_nonnull to infallible allocators |
| Previous Message | Ilia Evdokimov | 2026-09-29 06:23:58 | Skip LEFT/ANTI joins to a provably empty inner rel |