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. Regards, Tatsuya Kawata
