On Fri, Dec 22, 2023 at 8:14 AM Andrey M. Borodin <x4...@yandex-team.ru> 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...
This is an interesting idea. A variant would be to stripe across cachelines within the same page rather than across pages. If we do stripe across pages as proposed here, we'd probably want to rethink the way the SLRU is extended -- page at a time wouldn't really make sense, but preallocating an entire file might. > 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. -- Robert Haas EDB: http://www.enterprisedb.com
