Re: Bypassing shared_buffers

Поиск
Список
Период
Сортировка
От Andrey M. Borodin
Тема Re: Bypassing shared_buffers
Дата
Msg-id FA19D32A-3EF0-4432-94F5-B95C1F6D532C@yandex-team.ru
обсуждение исходный текст
Ответ на Bypassing shared_buffers  (Vladimir Churyukin <vladimir@churyukin.com>)
Список pgsql-hackers
Hi!

> On 15 Jun 2023, at 03:57, Vladimir Churyukin <vladimir@churyukin.com> wrote:
>
> Hello,
>
> There is often a need to test particular queries executed in the worst-case scenario, i.e. right after a server
restartor with no or minimal amount of data in shared buffers. In Postgres it's currently hard to achieve (other than
torestart the server completely to run a single query, which is not practical). Is there a simple way to introduce a
GUCvariable that makes queries bypass shared_buffers and always read from storage? It would make testing like that
ordersof magnitude simpler. I mean, are there serious technical obstacles or any other objections to that idea in
principle? 

Few months ago I implemented "drop of caches" to demonstrate basic structure of shared buffers [0]. The patch is very
unsafein the form is was implemented, but if you think that functionality is really useful (it was not intended to be)
Ican try to do the same as extension. 

it worked like "SELECT FlushAllBuffers();" and what is done resembles checkpoint, but evicts every buffer that can be
evicted.Obviously, emptied buffers would be immediately reused by concurrent sessions. 


Best regards, Andrey Borodin.

[0] https://www.youtube.com/watch?v=u8BAOqeKnwY


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: Deleting prepared statements from libpq.
Следующее
От: Schoemans Maxime
Дата:
Сообщение: Re: Implement missing join selectivity estimation for range types