Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
x4mmm@yandex-team.ru
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-04T20:07:52Z
Lists: pgsql-hackers
> On 30 Oct 2023, at 09:20, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > changed the logic of SlruAdjustNSlots() in 0002, such that now it > starts with the next power of 2 value of the configured slots and > keeps doubling the number of banks until we reach the number of banks > to the max SLRU_MAX_BANKS(128) and bank size is bigger than > SLRU_MIN_BANK_SIZE (8). By doing so, we will ensure we don't have too > many banks There was nothing wrong with having too many banks. Until bank-wise locks and counters were added in later patchsets. Having hashtable to find SLRU page in the buffer IMV is too slow. Some comments on this approach can be found here [0]. I'm OK with having HTAB for that if we are sure performance does not degrade significantly, but I really doubt this is the case. I even think SLRU buffers used HTAB in some ancient times, but I could not find commit when it was changed to linear search. Maybe we could decouple locks and counters from SLRU banks? Banks were meant to be small to exploit performance of local linear search. Lock partitions have to be bigger for sure. > On 30 Oct 2023, at 09:20, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > I have taken 0001 and 0002 from [1], done some bug fixes in 0001 BTW can you please describe in more detail what kind of bugs? Thanks for working on this! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/CA%2BhUKGKVqrxOp82zER1%3DXN%3DyPwV_-OCGAg%3Dez%3D1iz9rG%2BA7Smw%40mail.gmail.com#b60f1cb73d350cf686338d4e800e12a2
Commits
-
Fix zeroing of pg_serial page without SLRU bank lock
- be2f07310063 17.0 landed
-
Fix misspelled assertions
- 0d3a71d0c8a7 17.0 landed
-
GUC table: Add description to computed variables
- 30b8d6e4ce11 17.0 landed
-
Improve performance of subsystems on top of SLRU
- 53c2a97a9266 17.0 landed
-
Rename SLRU elements in view pg_stat_slru
- bcdfa5f2e2f2 17.0 landed
-
Use atomic access for SlruShared->latest_page_number
- d172b717c6f4 17.0 landed
-
Split use of SerialSLRULock, creating SerialControlLock
- 7b745d85b80d 17.0 landed
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 cited
-
Add a macro templatized hashtable.
- b30d3ea824c5 10.0 cited