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.
