Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
| От | Andrey M. Borodin |
|---|---|
| Тема | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
| Дата | |
| Msg-id | 83667B83-FE76-437D-99B7-AD899E6A8D92@yandex-team.ru обсуждение исходный текст |
| Ответ на | 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 |
On 19 Dec 2023, at 10:34, Dilip Kumar <dilipbalaut@gmail.com> wrote:
Just a side node.
It seems like commit log is kind of antipattern of data contention. Even when we build a super-optimized SLRU. Nearby **bits** are written by different CPUs.
I think that banks and locks are good thing. But also we could reorganize log so that
status of transaction 0 is on a page 0 at bit offset 0
status of transaction 1 is on a page 1 at bit offset 0
status of transaction 2 is on a page 2 at bit offset 0
status of transaction 3 is on a page 3 at bit offset 0
status of transaction 4 is on a page 0 at bit offset 2
status of transaction 5 is on a page 1 at bit offset 2
status of transaction 6 is on a page 2 at bit offset 2
status of transaction 7 is on a page 3 at bit offset 2
etc...
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?
This does not matter much because
0. Patch set in current thread produces robust SLRU anyway
1. One day we are going to throw away SLRU anyway
Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: