On Fri, 11 Aug 2023 at 13:54, Ron <ronljohnsonjr@gmail.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