Thread: Allow processes to reset procArrayGroupNext themselves instead of leader resetting for all the followers

Hi,

While working on something else, I noticed that the proc array group
XID clearing leader resets procArrayGroupNext of all the followers
atomically along with procArrayGroupMember. ISTM that it's enough for
the followers to exit the wait loop and continue if the leader resets
just procArrayGroupMember, the followers can reset procArrayGroupNext
by themselves. This relieves the leader a bit, especially when there
are many followers, as it avoids a bunch of atomic writes and
pg_write_barrier() for the leader .

I'm attaching a small patch with the above change. It doesn't seem to
break anything, the cirrus-ci members are happy
https://github.com/BRupireddy/postgres/tree/allow_processes_to_reset_proc_array_v1.
It doesn't seem to show visible benefit on my system, nor hurt anyone
in my testing [1].

Thoughts?

[1]
# of clients    HEAD    PATCHED
1    31661    31512
2    67134    66789
4    135084    132372
8    254174    255384
16    418598    420903
32    491922    494183
64    509824    509451
128    513298    512838
256    505191    496266
512    465208    453588
768    431304    425736
1024    398110    397352
2048    308732    308901
4096    200355    219480

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment
Hi,

On 2022-11-24 10:43:46 +0530, Bharath Rupireddy wrote:
> While working on something else, I noticed that the proc array group
> XID clearing leader resets procArrayGroupNext of all the followers
> atomically along with procArrayGroupMember. ISTM that it's enough for
> the followers to exit the wait loop and continue if the leader resets
> just procArrayGroupMember, the followers can reset procArrayGroupNext
> by themselves. This relieves the leader a bit, especially when there
> are many followers, as it avoids a bunch of atomic writes and
> pg_write_barrier() for the leader .

I doubt this is a useful change - the leader already has to modify the
relevant cacheline (for procArrayGroupMember). That makes it pretty much free
to modify another field in the same cacheline.

Greetings,

Andres Freund



On Sun, Nov 27, 2022 at 2:48 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-11-24 10:43:46 +0530, Bharath Rupireddy wrote:
> > While working on something else, I noticed that the proc array group
> > XID clearing leader resets procArrayGroupNext of all the followers
> > atomically along with procArrayGroupMember. ISTM that it's enough for
> > the followers to exit the wait loop and continue if the leader resets
> > just procArrayGroupMember, the followers can reset procArrayGroupNext
> > by themselves. This relieves the leader a bit, especially when there
> > are many followers, as it avoids a bunch of atomic writes and
> > pg_write_barrier() for the leader .
>
> I doubt this is a useful change - the leader already has to modify the
> relevant cacheline (for procArrayGroupMember). That makes it pretty much free
> to modify another field in the same cacheline.

Agreed. Thanks for the response.

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com