From: | Vladimir Churyukin <vladimir(at)churyukin(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bypassing shared_buffers |
Date: | 2023-06-15 02:52:57 |
Message-ID: | CAFSGpE1nkJFHeEdz1hpFJt6G6vzHN+G2_cM0nupo_mdi-O7t=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-06-15 04:10:44 | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
Previous Message | Vladimir Churyukin | 2023-06-15 02:51:03 | Re: Bypassing shared_buffers |