From: | Sergey Sergey <ioxgrey(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] fastpacth-locks compile time options |
Date: | 2023-09-19 06:01:09 |
Message-ID: | CAOC4_yoaiQ4vnOVVwq+0XKNFHy4WTnva1dXZA-1NH4CVxy2FfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you for response.
On Tue, Sep 19, 2023 at 2:52 AM Michael Paquier <michael(at)paquier(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2023-09-19 06:17:45 | RE: [PoC] pg_upgrade: allow to upgrade publisher node |
Previous Message | Michael Paquier | 2023-09-19 05:43:37 | Re: Move global variables of pgoutput to plugin private scope. |