Re: Proposal: SLRU to Buffer Cache

Hi,

On 2018-08-22 13:35:47 +0500, Andrey Borodin wrote:
> > 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.

Yea, I don't think it really makes sense to reimplement this logic for
SLRUs (and then UNDO) separately.

> > 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?

I think it's not an absurd idea to put the reserved oid into pg_am
(under a separate amtype). Although the fact that shared entries would
be in database local tables is a bit weird. But I'm fairly certain that
we'd not put any actual data into it, not the least because we need to
be able to acess clo etc from connections that cannot attach to a
database (say the startup process, which will never ever start reading
from a catalog table). So I don't really see what you mean with:

> 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.

that doesn't really seem like it could work. Nor am I even clear what
the above points really have to do with the AM layer.

Greetings,

Andres Freund