Re: Proposal: SLRU to Buffer Cache - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Proposal: SLRU to Buffer Cache
Date
Msg-id 7E572B03-CD7E-4D8D-B7D4-0A343AF419CA@yandex-team.ru
Whole thread Raw
In response to Proposal: SLRU to Buffer Cache  (Shawn Debnath <sdn@amazon.com>)
Responses Re: Proposal: SLRU to Buffer Cache
List pgsql-hackers
Hi!

> 15 авг. 2018 г., в 2:35, Shawn Debnath <sdn@amazon.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
sizeand ability to truncate unneeded pages. This may to be useful, for example, in LSM tree implementation or something
similar.

Best regards, Andrey Borodin.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: JIT compiling with LLVM v12
Next
From: Masahiko Sawada
Date:
Subject: Re: Two proposed modifications to the PostgreSQL FDW