Re: [PATCH] fastpacth-locks compile time options - Mailing list pgsql-hackers

From Sergey Sergey
Subject Re: [PATCH] fastpacth-locks compile time options
Date
Msg-id CAOC4_yoaiQ4vnOVVwq+0XKNFHy4WTnva1dXZA-1NH4CVxy2FfQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] fastpacth-locks compile time options  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Thank you for response.

On Tue, Sep 19, 2023 at 2:52 AM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Sep 18, 2023 at 05:49:51PM +0300, Sergey Sergey wrote:
> Hope this patch will be usefull/

-    uint64       fpLockBits;        /* lock modes held for each fast-path slot */
+    uint8        fpLockBits[FP_LOCK_SLOTS_PER_BACKEND];        /* lock modes

If my maths are right, this makes PGPROC 8 bytes larger with 16 slots
by default.  That is not a good idea.

You maths are correct. I can't estimate overall effect of this PGPROC grows. 
Our typical setup include 768Gb RAM. It looks like space-for-time optimization.
I check ordinary pgbench for patched and unpatched version.Total average tps
are the same. Patched version has very stable tps values during test.

+  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]

And this points out that ./configure has been generated with one of
Debian's autoreconf commands, which is something to avoid.

Yes, first i try to build it Debian way.
I can rebuild ./configure with autoconf.
 

I am not sure that this patch is a good idea long-term.  Wouldn't it
be better to invent new and more scalable concepts able to tackle
bottlenecks around these code paths instead of using compile-time
tweaks like that?

Another one way is to replace fixed arrays inside PGPROC

uint8           fpLockBits[FP_LOCK_SLOTS_PER_BACKEND];          /* lock modes 
Oid             fpRelId[FP_LOCK_SLOTS_PER_BACKEND]; /* slots for rel oids */

with pointers to arrays allocated outside PGPROC.

We also can use c99 flexible array pointers feature. This way we should make
structure like

struct FPLock
{
    uint8 fpLockBit;
    Oid   fpRelid;
}

Set the array of struct FPLock at the end of PGPROC structure. And calculate memory 
allocation for PGPROC using some GUC variable.

This two ways seems so complex for me.

 
--
Michael

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Move global variables of pgoutput to plugin private scope.
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node