Horton

Re: BitmapHeapScan streaming read user and prelim refactoring

Melanie Plageman <melanieplageman@gmail.com>

View thread View on postgr.es
From: Melanie Plageman <melanieplageman@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>, Andres Freund <andres@anarazel.de>, Pg Hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-01-30T23:10:30Z
Lists: pgsql-hackers 
On Tue, Mar 19, 2024 at 4:34 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 3/18/24 16:55, Tomas Vondra wrote:
> >
> > ...
> >
> > OK, I've restarted the tests for only 0012 and 0014 patches, and I'll
> > wait for these to complete - I don't want to be looking for patterns
> > until we have enough data to smooth this out.
> >
> >
>
> I now have results for 1M and 10M runs on the two builds (0012 and
> 0014), attached is a chart for relative performance plotting
>
>   (0014 timing) / (0012 timing)
>
> for "optimal' runs that would pick bitmapscan on their own. There's
> nothing special about the config - I reduced the random_page_cost to
> 1.5-2.0 to reflect both machines have flash storage, etc.
>
> Overall, the chart is pretty consistent with what I shared on Sunday.
> Most of the results are fine (0014 is close to 0012 or faster), but
> there's a bunch of cases that are much slower. Interestingly enough,
> almost all of them are on the i5 machine, almost none of the xeon. My
> guess is this is about the SSD type (SATA vs. NVMe).
>
> Attached if table of ~50 worst regressions (by the metric above), and
> it's interesting the worst regressions are with eic=0 and eic=1.
>
> I decided to look at the first case (eic=0), and the timings are quite
> stable - there are three runs for each build, with timings close to the
> average (see below the table).
>
> Attached is a script that reproduces this on both machines, but the
> difference is much more significant on i5 (~5x) compared to xeon (~2x).
>
> I haven't investigated what exactly is happening and why, hopefully the
> script will allow you to reproduce this independently. I plan to take a
> look, but I don't know when I'll have time for this.
>
> FWIW if the script does not reproduce this on your machines, I might be
> able to give you access to the i5 machine. Let me know.

I had this particular email on this thread bookmarked so I could go
back and investigate the regression. The patch set has changed since
these benchmarks were run. And, I honestly no longer remember what
0014 and 0012 were. There are four remaining patches in the set I
posted earlier today in [1]. All of them are directly related to
bitmap heap scan using the streaming read interface (i.e. not useful
on their own). Therefore, it is time to investigate if we should merge
streaming read bitmap heap scan.

I ran the query included in the reproducer in this mail a dozen times
on master and with the patches in [1] and the average speedup with my
patch is 12%. So, at least for this query, I don't see a regression.

What do you think about rerunning these old benchmarks to see what
they look like now?

- Melanie

[1] https://www.postgresql.org/message-id/CAAKRu_as499kHb9B4B4%3D%2Bc%2B4p%2BOF_Bibd4KEdoqyBgjEaEUdgA%40mail.gmail.com

Commits

  1. Fix bitmapheapscan incorrect recheck of NULL tuples

  2. Increase default maintenance_io_concurrency to 16

  3. Separate TBM[Shared|Private]Iterator and TBMIterateResult

  4. Improve read_stream.c advice for dense streams.

  5. Increase default effective_io_concurrency to 16

  6. Delay extraction of TIDBitmap per page offsets

  7. Add lossy indicator to TBMIterateResult

  8. Move BitmapTableScan per-scan setup into a helper

  9. Add and use BitmapHeapScanDescData struct

  10. Fix bitmap table scan crash on iterator release

  11. Bitmap Table Scans use unified TBMIterator

  12. Add common interface for TBMIterators

  13. Make table_scan_bitmap_next_block() async-friendly

  14. Move EXPLAIN counter increment to heapam_scan_bitmap_next_block

  15. Refactor tidstore.c iterator buffering.

  16. BitmapHeapScan: Remove incorrect assert and reset field

  17. Change BitmapAdjustPrefetchIterator to accept BlockNumber

  18. BitmapHeapScan: Use correct recheck flag for skip_fetch

  19. BitmapHeapScan: Push skip_fetch optimization into table AM

  20. BitmapHeapScan: postpone setting can_skip_fetch

  21. BitmapHeapScan: begin scan after bitmap creation

  22. Fix EXPLAIN Bitmap heap scan to count pages with no visible tuples

  23. Remove redundant snapshot copying from parallel leader to workers

  24. Remove some obsolete smgrcloseall() calls.

  25. Remove the "snapshot too old" feature.

  26. Compute XID horizon for page level index vacuum on primary.