Re: Add parallel columns for pg_stat_statements

On Mon, Oct 07, 2024 at 10:00:13AM +0200, Guillaume Lelarge wrote:
> Le lun. 7 oct. 2024 à 02:18, Michael Paquier <michael@paquier.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. 
- 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.
- Meson was not updated for the new test and the files to install.

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.

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