Re: pb with big volumes

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ron <ronljohnsonjr(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: pb with big volumes
Date: 2023-08-11 04:40:52
Message-ID: CAApHDvoApBdOLyRp+fj3_bcSJeYbJg_R0RdBiY__5TJ8j8Zf5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 11 Aug 2023 at 13:54, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
> Wouldn't IO contention make for additive timings instead of exponential?

No, not necessarily. Imagine one query running that's doing a
parameterised nested loop join resulting in the index on the inner
side being descended several, say, million times. Let's say there's
*just* enough RAM/shared buffers so that the index pages, once the
index is scanned the first time, all the required pages are cached
which results in no I/O on subsequent index scans. Now, imagine
another similar query but with another index, let's say this index
also *just* fits in cache. Now, when these two queries run
concurrently, they each evict buffers the other one uses. Of course,
the shared buffers code is written in such a way as to try and evict
lesser used buffers first, but if they're all used about the same
amount, then this can stuff occur. The slowdown isn't linear.

I've no idea if this is happening for the reported case. I'm just
saying that it can happen. The OP should really post the results of:
SET track_io_timing = ON; EXPLAIN (ANALYZE, BUFFERS) for both queries
running independently then again when they run concurrently.

David
David

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc Millas 2023-08-11 10:17:26 Re: pb with big volumes
Previous Message Ron 2023-08-11 01:53:54 Re: pb with big volumes