Re: index prefetching - Mailing list pgsql-hackers

From Alexandre Felipe
Subject Re: index prefetching
Date
Msg-id CAE8JnxNKWnNAg0dRkO43=W1GUVt1GDAGnhfw1cdDUbeYrS6HDA@mail.gmail.com
Whole thread
In response to Re: index prefetching  (Tomas Vondra <tomas@vondra.me>)
Responses Re: index prefetching
List pgsql-hackers
Hi Tomas,

> I've decided to run a couple tests, trying to reproduce some of the
> behaviors described in your (Felipe's) messages.
> ...
> I'm attaching the full scripts, raw results, and PDFs with a nicer
> version of the results.

> The results are pretty positive. For random data (which is about the
> worst case for I/O), it's consistently faster than master. Yes, the
> gains with 8 workers is not as significant as with 1 worker. For
> example, it may look like this:
>
>               master      prefetch
>   1 worker:     2960          1898       64%
>   8 workers:    5585          5361       96%

branch: patched
data: random
io: buffered

          patched          master      
iomethod io_uring worker io_uring worker
workers                                
1            1.52   1.29     2.79   2.75
2            1.77   1.63     3.03   3.04
4            2.36   4.24     3.44   3.40
8            3.60   8.53     4.30   4.30


They are about the same for 1 worker, but degrade as the number of 
workers increase, to be honest I was expecting this behaviour IO not
with buffered. But as you pointed out using io_unring the issue goes
away.

Lock contention in pgaio_worker_submit_internal?
Or maybe nsync > 0 at the bottom of the function?
(in src/backend/storage/aio/method_worker.c)

Regards

Attachment

pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
Next
From: Richard Guo
Date:
Subject: Re: Convert NOT IN sublinks to anti-joins when safe