Re: Bypassing shared_buffers - Mailing list pgsql-hackers

From Vladimir Churyukin
Subject Re: Bypassing shared_buffers
Date
Msg-id CAFSGpE1nkJFHeEdz1hpFJt6G6vzHN+G2_cM0nupo_mdi-O7t=g@mail.gmail.com
Whole thread Raw
In response to Re: Bypassing shared_buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
It could be cheaper, if the testing is done for many SELECT queries sequentially - you need to flush dirty buffers just once pretty much.

-Vladimir Churyukin

On Wed, Jun 14, 2023 at 7:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
> There are two levels of cache.  If you're on Linux you can ask it to
> drop its caches by writing certain values to /proc/sys/vm/drop_caches.
> For PostgreSQL's own buffer pool, it would be nice if someone would
> extend the pg_prewarm extension to have a similar 'unwarm' operation,
> for testing like that.  But one thing you can do is just restart the
> database cluster, or use pg_prewarm to fill its buffer pool up with
> other stuff (and thus kick out the stuff you didn't want in there).

But that'd also have to push out any dirty buffers.  I'm skeptical
that it'd be noticeably cheaper than stopping and restarting the
server.

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Vladimir Churyukin
Date:
Subject: Re: Bypassing shared_buffers
Next
From: Nathan Bossart
Date:
Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX