Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Date | |
Msg-id | 202402261616.dlriae7b6emv@alvherre.pgsql Whole thread Raw |
In response to | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock (Dilip Kumar <dilipbalaut@gmail.com>) |
Responses |
Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
|
List | pgsql-hackers |
On 2024-Feb-23, Dilip Kumar wrote: > 1. > + * If no process is already in the list, we're the leader; our first step > + * is to "close out the group" by resetting the list pointer from > + * ProcGlobal->clogGroupFirst (this lets other processes set up other > + * groups later); then we lock the SLRU bank corresponding to our group's > + * page, do the SLRU updates, release the SLRU bank lock, and wake up the > + * sleeping processes. > > I think here we are saying that we "close out the group" before > acquiring the SLRU lock but that's not true. We keep the group open > until we gets the lock so that we can get maximum members in while we > are anyway waiting for the lock. Absolutely right. Reworded that. > 2. > static void > TransactionIdSetCommitTs(TransactionId xid, TimestampTz ts, > RepOriginId nodeid, int slotno) > { > - Assert(TransactionIdIsNormal(xid)); > + if (!TransactionIdIsNormal(xid)) > + return; > + > + entryno = TransactionIdToCTsEntry(xid); > > I do not understand why we need this change. Ah yeah, I was bothered by the fact that if you pass Xid values earlier than NormalXid to this function, we'd reply with some nonsensical values instead of throwing an error. But you're right that it doesn't belong in this patch, so I removed that. Here's a version with these fixes, where I also added some text to the pg_stat_slru documentation: + <para> + For each <literal>SLRU</literal> area that's part of the core server, + there is a configuration parameter that controls its size, with the suffix + <literal>_buffers</literal> appended. For historical + reasons, the names are not exact matches, but <literal>Xact</literal> + corresponds to <literal>transaction_buffers</literal> and the rest should + be obvious. + <!-- Should we edit pgstat_internal.h::slru_names so that the "name" matches + the GUC name?? --> + </para> I think I would like to suggest renaming the GUCs to have the _slru_ bit in the middle: +# - SLRU Buffers (change requires restart) - + +#commit_timestamp_slru_buffers = 0 # memory for pg_commit_ts (0 = auto) +#multixact_offsets_slru_buffers = 16 # memory for pg_multixact/offsets +#multixact_members_slru_buffers = 32 # memory for pg_multixact/members +#notify_slru_buffers = 16 # memory for pg_notify +#serializable_slru_buffers = 32 # memory for pg_serial +#subtransaction_slru_buffers = 0 # memory for pg_subtrans (0 = auto) +#transaction_slru_buffers = 0 # memory for pg_xact (0 = auto) and the pgstat_internal.h table: static const char *const slru_names[] = { "commit_timestamp", "multixact_members", "multixact_offsets", "notify", "serializable", "subtransaction", "transaction", "other" /* has to be last */ }; This way they match perfectly. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "All rings of power are equal, But some rings of power are more equal than others." (George Orwell's The Lord of the Rings)
Attachment
pgsql-hackers by date: