From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Shawn Debnath <sdn(at)amazon(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: SLRU to Buffer Cache |
Date: | 2018-08-22 08:35:47 |
Message-ID: | 7E572B03-CD7E-4D8D-B7D4-0A343AF419CA@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
> 15 авг. 2018 г., в 2:35, Shawn Debnath <sdn(at)amazon(dot)com> написал(а):
>
> At the Unconference in Ottawa this year, I pitched the idea of moving
> components off of SLRU and on to the buffer cache. The motivation
> behind the idea was three fold:
>
> * Improve performance by eliminating fixed sized caches, simplistic
> scan and eviction algorithms.
> * Ensuring durability and consistency by tracking LSNs and checksums
> per block.
+1, I like this idea more than current patch on CF with checksums for SLRU pages.
> 1. Implement a generic block storage manager that parameterizes
> several options like segment sizes, fork and segment naming and
> path schemes, concepts entrenched in md.c that are strongly tied to
> relations. To mitigate risk, I am planning on not modifying md.c
> for the time being.
Probably I'm missing something, but why this should not be in access methods? You can extend AM to control it's segment size and ability to truncate unneeded pages. This may to be useful, for example, in LSM tree implementation or something similar.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2018-08-22 09:29:44 | Re: Two proposed modifications to the PostgreSQL FDW |
Previous Message | Andres Freund | 2018-08-22 08:15:18 | Re: JIT compiling with LLVM v12 |