Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
От | Alvaro Herrera |
---|---|
Тема | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Дата | |
Msg-id | 202402061525.nq7yftgcs22v@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
|
Список | pgsql-hackers |
Here's the rest of it rebased on top of current master. I think it makes sense to have this as one individual commit. I made CLOGShmemBuffers, CommitTsShmemBuffers and SUBTRANSShmemBuffers compute a number that's multiple of SLRU_BANK_SIZE. But it's a crock, because we don't have that macro at that point, so I just used constant 16. Obviously need a better solution for this. I also changed the location of bank_mask in SlruCtlData for better packing, as advised by pahole; and renamed SLRU_SLOTNO_GET_BANKLOCKNO() to SlotGetBankNumber(). Some very critical comments still need to be updated to the new design, particularly anything that mentions "control lock"; but also the overall model needs to be explained in some central location, rather than incongruently some pieces here and other pieces there. I'll see about this later. But at least this is code you should be able to play with. I've been wondering whether we should add a "slru" to the name of the GUCs: commit_timestamp_slru_buffers transaction_slru_buffers etc -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio)
Вложения
В списке pgsql-hackers по дате отправления: