From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BitmapHeapScan streaming read user and prelim refactoring |
Date: | 2025-03-13 21:41:14 |
Message-ID: | CAAKRu_b8nJua_W_C1i46a-XaMzJJnYF+8BpET0zyoREXEvrmhQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 10, 2025 at 7:45 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> Attached v35 0003-0005 is the same as v34 but is on top of two new
> commits: 0001 increases the default effective_io_concurrency to 16 and
> 0002 adds a READ_STREAM_RANDOM flag which disables sequential
> detection and is used by bitmap heap scan.
Attached v36 is built on top of the read stream updates Thomas posted
earlier today in [1]. I've been doing some performance testing and
from what I see, we've closed the major gaps.
The case I was most concerned about was cyclic data (narrow bands of
sequential data in a larger random dataset) with reasonable values for
io_combine_limit, effective_io_concurrency, and OS read ahead. I've
attached a chart which compares the query time for master, my original
bitmap heap scan streaming read user "og", the bitmap heap scan
streaming read user with sequential detection turned off completely
"random", and the bitmap heap scan streaming read user with the
updated read stream changes Thomas posted today "rsupdate". You can
see that it eliminates the regression.
For some of the other cases, because we still do sequential detection
with Thomas' changes, we sometimes pause prefetching which means if
you have turned off OS read ahead, then it'll be slower than without
the read stream user. That's okay, though -- in the vastly more common
case of OS readahead being enabled, we can avoid unnecessary
prefetching and beat current master.
Overall, I feel pretty good about merging this once Thomas merges the
read stream patches.
- Melanie
Attachment | Content-Type | Size |
---|---|---|
v36-0005-Support-buffer-forwarding-in-read_stream.c.patch | text/x-patch | 8.7 KB |
v36-0002-Respect-pin-limits-accurately-in-read_stream.c.patch | text/x-patch | 9.6 KB |
v36-0001-Improve-buffer-manager-API-for-backend-pin-limit.patch | text/x-patch | 6.9 KB |
v36-0003-Improve-read-stream-advice-for-large-random-chun.patch | text/x-patch | 7.4 KB |
v36-0004-Look-ahead-more-when-sequential-in-read_stream.c.patch | text/x-patch | 7.2 KB |
v36-0006-Support-buffer-forwarding-in-StartReadBuffers.patch | text/x-patch | 10.5 KB |
v36-0007-Separate-TBM-Shared-Private-Iterator-and-TBMIter.patch | text/x-patch | 19.4 KB |
v36-0009-Remove-table-AM-callback-scan_bitmap_next_block.patch | text/x-patch | 22.8 KB |
v36-0008-BitmapHeapScan-uses-the-read-stream-API.patch | text/x-patch | 28.9 KB |
![]() |
image/png | 59.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-03-13 21:51:52 | Re: making EXPLAIN extensible |
Previous Message | Daniel Gustafsson | 2025-03-13 21:41:12 | Re: ecdh support causes unnecessary roundtrips |