From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Marc Millas <marc(dot)millas(at)mokadb(dot)com> |
Cc: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pb with big volumes |
Date: | 2023-08-13 23:24:39 |
Message-ID: | CAApHDvr90RbUTbijJHOgE1DYptYo3murM0nnFH+oyE9ROr7u-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 14 Aug 2023 at 11:14, Marc Millas <marc(dot)millas(at)mokadb(dot)com> wrote:
> that's exactly my question.
> does the analyze buffers data, generated when track_io_timing is on, keep track of multiple reloads of the same data while executing one operation ?
Yes, the timing for reads will include the time it took to fetch any
buffer that wasn't found in shared buffers. Some of those may come
quickly from the kernel's page cache, some might come from disk. If
some other running query has evicted a buffer that the query has
previously used, then that's going to cause another pread, which will
be timed by track_io_timing and added to the count of buffers read in
the "BUFFERS" EXPLAIN output.
So, the BUFFERs EXPLAIN option showing similar amounts of reads
between the query running without the concurrent query and with the
concurrent query does not necessarily mean more buffers had to be
loaded from disk, just that fewer were found in shared buffers. The
amount of time doing I/O as shown by track_io_timing is going to be
more interesting as that's really the only indication from within
PostgreSQL that you have to get an idea of if the buffers are coming
from the kernel's cache or from disk. You'll probably want to
calculate the average time it took to get 1 buffer for each query to
make sense of that.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Diangelo | 2023-08-14 09:51:23 | Best strategy to perform individual incremental backups |
Previous Message | Marc Millas | 2023-08-13 23:14:38 | Re: pb with big volumes |