Re: Bypassing shared_buffers - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: Bypassing shared_buffers
Date
Msg-id FA19D32A-3EF0-4432-94F5-B95C1F6D532C@yandex-team.ru
Whole thread Raw
In response to Bypassing shared_buffers  (Vladimir Churyukin <vladimir@churyukin.com>)
List 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 by date:

Previous
From: Jelte Fennema
Date:
Subject: Re: Deleting prepared statements from libpq.
Next
From: Schoemans Maxime
Date:
Subject: Re: Implement missing join selectivity estimation for range types