public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexandre Felipe <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Georgios <[email protected]>
Cc: Konstantin Knizhnik <[email protected]>
Cc: Dilip Kumar <[email protected]>
Subject: Re: index prefetching
Date: Sun, 8 Mar 2026 06:16:00 +0000
Message-ID: <CAE8JnxNKWnNAg0dRkO43=W1GUVt1GDAGnhfw1cdDUbeYrS6HDA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAE8JnxN_EwnTLLMWGhvgwaomYZ0ysm7NeogA-BqBd=Rs3S7Oqw@mail.gmail.com>
<64a2re223ajj4popowsyu4xekbuvvyfwkrihn5yzyrkwsmsuvp@2lls3tpww5dl>
<a67mvhyi2q45eg4eimhpwdg6l3s3dmpahti2svffvmvzwmss27@r4nohusvndbq>
<[email protected]>
<il7jtfowpatrlg33qb5plj7v7pferes4ogerq5fdczszi4kokh@sbwvb2ukfgos>
<[email protected]>
<ws47e3wly6skt36b23zy5qfvcxzueo6od3uicunuodsqnxl7os@7v2qi7qkxzbz>
<CAH2-Wzk-89uCvdJ1Q6NsM6LvDvUEt6Qy66T6A60J=D_voWxZDg@mail.gmail.com>
<64mfcfv7iihc4pmqlxarii4esnmqry52ckz5m7lmwylnfnuxuz@oxh4ioxkjtep>
<CAH2-Wzmy7NMba9k8m_VZ-XNDZJEUQBU8TeLEeL960-rAKb-+tQ@mail.gmail.com>
<issqornf6vdn3vb64fjuoathypmu3e5pgputd3lpfuvoeqyvzr@qfordnhplp2v>
<CAE8JnxOn4+xUAnce+M7LfZWOqfrMMxasMaEmSKwiKbQtZr65uA@mail.gmail.com>
<[email protected]>
<[email protected]>
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
Attachments:
[application/gzip] multi-client-experiment.ipynb.gz (31.2K, 3-multi-client-experiment.ipynb.gz)
download
[application/gzip] multi-client-experiment.html.gz (105.3K, 4-multi-client-experiment.html.gz)
download
view thread (367+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: index prefetching
In-Reply-To: <CAE8JnxNKWnNAg0dRkO43=W1GUVt1GDAGnhfw1cdDUbeYrS6HDA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox