Re: Proposal: SLRU to Buffer Cache

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: Proposal: SLRU to Buffer Cache
Дата
Msg-id 7E572B03-CD7E-4D8D-B7D4-0A343AF419CA@yandex-team.ru
обсуждение исходный текст
Ответ на Proposal: SLRU to Buffer Cache  (Shawn Debnath <sdn@amazon.com>)
Ответы Re: Proposal: SLRU to Buffer Cache  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: JIT compiling with LLVM v12
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Two proposed modifications to the PostgreSQL FDW