| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Lars Bergeson <larsavatar(at)gmail(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Query is slower with a large proportion of NULLs in several columns |
| Date: | 2021-12-21 05:08:59 |
| Message-ID: | CAKFQuwZ==D+f656wsZcctpChQ2xWx5t2fjEhr8+VQWCSCWaWgQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Monday, December 20, 2021, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > On Mon, Dec 20, 2021 at 08:11:42PM -0800, Lars Bergeson wrote:
> >> Still taking 10X more I/O to read the smaller table. Very odd.
>
> > If I'm not wrong, it's even worse than that ?
> > It takes 20 or 30sec to run the query - but it says the associated I/O
> times
> > are ~500sec or ~6000sec ?
>
> It would help if somebody had labeled the units of I/O Time
> ... but I'm guessing those are microsec vs. the millisec
> of the other times, because otherwise it's completely wrong.
>
>
Related to my preceding observation, from the explain (buffers) docs:
“…and the time spent reading and writing data file blocks (in milliseconds)
if track_io_timing
<https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING>
is
enabled.“
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-12-21 05:33:06 | Re: Query is slower with a large proportion of NULLs in several columns |
| Previous Message | David G. Johnston | 2021-12-21 05:07:01 | Re: Query is slower with a large proportion of NULLs in several columns |