Re: Add parallel columns for pg_stat_statements

Hi,

Le mar. 8 oct. 2024 à 09:29, Michael Paquier <michael(at)paquier(dot)xyz> a écrit :

> On Mon, Oct 07, 2024 at 10:00:13AM +0200, Guillaume Lelarge wrote:
> > Le lun. 7 oct. 2024 à 02:18, Michael Paquier <michael(at)paquier(dot)xyz> a
> écrit :
> >> I'd recommend to split that into more independent patches:
> >> - Introduce the two counters in EState with the incrementations done
> >> in nodeGatherMerge.c and nodeGather.c (mentioned that at [2], you may
> >> want to coordinate with Benoit to avoid duplicating the work).
> >> - Expand pg_stat_statements to use them for DMLs, SELECTs, well where
> >> they matter.
> >> - Look at expanding that for utilities that can do parallel jobs:
> >> CREATE INDEX and VACUUM, but this has lower priority to me, and this
> >> can reuse the same counters as the ones added by patch 2.
> >
> > The first two are done. The last one is beyond my scope.
>
> That's fair. I have put my hands on this patch set, finishing with
> the attached.
>
> A couple of notes:
> - I've been struggling a bit on the "planned" vs "launched" terms used
> in the names for the counters. It is inconsistent with the backend
> state, where we talk about workers "to launch" and workers "launched".
> "planned" does not really apply to utilities, as this may not be
> planned per se.
>

You're right. Much better to keep them consistent.

> - The test in parallel.sql can be cheaper, tweaking the right GUCs the
> right way data in the table is not even required to spawn a set of
> parallel workers.
>

Yeah, it could be cheaper. As it is already quick, I didn't do the extra
mile to make it cheaper.

> - Meson was not updated for the new test and the files to install.
>
>
Oops, sorry. Didn't know that Meson had to be updated.

> 0001 and 0002 are the parts of the patch that I can see myself
> applying; it is pretty cool to see pg_stat_statements complain that
> the launched/to_launch ratio can get unbalanced really quickly when I
> do something stupid. The CI is stable with these.
>
>
Great, thanks :)

> 0003 has the remaining bits with the 3rd and 4th counters, able to
> apply on top of 0002.
>

Still think they are interesting but I understand your concerns.

I've done a bit of testing with the three patches, and didn't find any
issue with them.

--
Guillaume.