Hi Bertrand-san,
Thanks for the explanation!
> I think that flushing statistics within running transactions [1] could help to
> see what's going on for parallel workers too.
Thanks, I'll follow that thread.
> For parallel workers this window
> is very short (between the flush and the exit) so that we can say that their stats
> are not visible in practice.
> That said, I'm not sure the doc needs any clarifications given that those functions
> take a PID as parameter and that they state something like "Returns I/O
> /WAL statistics about the backend with the specified process ID".
Right, it's per-PID, and that part is clear. My concern is that it isn't obvious from the function description that a single query can span more than one PID, as it does with parallel workers.
If it's worth documenting, I agree splitting it across lock / I/O / WAL separately isn't great -- a single place such as "Statistics Functions" seems better. Either way it's separate from this patch, so I'll start a dedicated thread with a draft.
> It's not related to this thread so that might be worth a dedicated one but I'm
> not sure that would be more actionable while consuming more resources.
Thanks -- agreed there's a tradeoff here. I can see a use case for it, so I'd like to weigh that against the cost and, if it still looks worth it, post it as a separate patch to get more opinions.
No need to reflect either of these in the current patch.
