Re: Proposal: SLRU to Buffer Cache

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.

In response to

Responses

Browse pgsql-hackers by date

  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