Hi Amit, Sorry I just noticed your mail.
On Sun, Mar 29, 2020 at 05:12:16PM +0530, Amit Kapila wrote: > On Sun, Mar 29, 2020 at 1:26 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > > > I'm not sure that I get your point. I'm assuming that you meant > > parallel-read-only queries, but surely buffer usage infrastructure for > > parallel query relies on the same approach as non-parallel one (each node > > computes the process-local pgBufferUsage diff) and sums all of that at the > > end > > of the parallel query execution. I also don't see how whether the query is > > read-only or not is relevant here as far as instrumentation is concerned, > > especially since read-only query can definitely do writes and increase the > > count of dirtied buffers, like a write query would. For instance a hint > > bit change can be done in a parallel query AFAIK, and this can generate WAL > > records in wal_log_hints is enabled, so that's probably one way to test it. > > > > Yeah, that way we can test it. Can you try that? > > > I now think that not adding support for WAL buffers in EXPLAIN output in the > > initial patch scope was a mistake, as this is probably the best way to test > > the > > WAL counters for parallel queries. This shouldn't be hard to add though, > > and I > > can work on it quickly if there's still a chance to get this feature > > included > > in pg13. > > > > I am not sure we will add it in Explain or not (maybe we need inputs > from others in this regard), but if it helps in testing this part of > the patch, then it is a good idea to write a patch for it. You might > want to keep it separate from the main patch as we might not commit > it. As I just wrote in [1] that's exactly what I did. Using parallel query and concurrent update on a table I could see that WAL usage for parallel query seems to be working as one could expect. > Sure, I am fine with that but I am not sure if it is a good idea to > commit this patch without having a way to compute WAL utilization for > those commands. I'm generally fine with waiting for a fix for the existing issue to be committed. But as the feature freeze is approaching, I hope that it won't mean postponing this feature to v14 because a related 2yo bug has just been discovered, as it would seem a bit unfair.