Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, tender wang <tndrwang@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-02T18:30:43Z
Lists: pgsql-hackers
On Tue, Jan 2, 2024 at 1:10 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
> > On 2 Jan 2024, at 19:23, Robert Haas <robertmhaas@gmail.com> wrote:
> >> And it would be even better if page for transaction statuses would be determined by backend id somehow. Or at least cache line. Can we allocate a range (sizeof(cacheline)) of xids\subxids\multixacts\whatever for each backend?
> >
> > I don't understand how this could work. We need to be able to look up
> > transaction status by XID, not backend ID.
>
> When GetNewTransactionId() is called we can reserve 256 xids in backend local memory. This values will be reused by transactions or subtransactions of this backend. Here 256 == sizeof(CacheLine).
> This would ensure that different backends touch different cache lines.
>
> But this approach would dramatically increase xid consumption speed on patterns where client reconnects after several transactions. So we can keep unused xids in procarray for future reuse.
>
> I doubt we can find significant performance improvement here, because false cache line sharing cannot be _that_ bad.

Yeah, this seems way too complicated for what we'd potentially gain
from it. An additional problem is that the xmin horizon computation
assumes that XIDs are assigned in monotonically increasing fashion;
breaking that would be messy. And even an occasional leak of XIDs
could precipitate enough additional vacuuming to completely outweigh
any gains we could hope to achieve here.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

  1. Fix zeroing of pg_serial page without SLRU bank lock

  2. Fix misspelled assertions

  3. GUC table: Add description to computed variables

  4. Improve performance of subsystems on top of SLRU

  5. Rename SLRU elements in view pg_stat_slru

  6. Use atomic access for SlruShared->latest_page_number

  7. Split use of SerialSLRULock, creating SerialControlLock

  8. Index SLRUs by 64-bit integers rather than by 32-bit integers

  9. Add a macro templatized hashtable.