Horton

Re: index prefetching

Tomas Vondra <tomas@vondra.me>

View thread
From: Tomas Vondra <tomas@vondra.me>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Nazir Bilal Yavuz <byavuz81@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Georgios <gkokolatos@protonmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2025-08-11T21:07:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. aio: io_uring: Trigger async processing for large IOs

  2. read stream: Split decision about look ahead for AIO and combining

  3. read_stream: Only increase read-ahead distance when waiting for IO

  4. read_stream: Prevent distance from decaying too quickly

  5. Reduce ExecSeqScan* code size using pg_assume()

  6. Fix rare bug in read_stream.c's split IO handling.

  7. Fix multiranges to behave more like dependent types.

  8. Add EXPLAIN (MEMORY) to report planner memory consumption

  9. Optimize nbtree backward scan boundary cases.

  10. Increment xactCompletionCount during subtransaction abort.

  11. Add nbtree Valgrind buffer lock checks.

  12. Add nbtree high key "continuescan" optimization.

  13. Reduce pinning and buffer content locking for btree scans.

  14. Teach btree to handle ScalarArrayOpExpr quals natively.

On 8/11/25 22:14, Peter Geoghegan wrote:
> On Mon, Aug 11, 2025 at 10:16 AM Tomas Vondra <tomas@vondra.me> wrote:
>> Perhaps. For me benchmarks are a way to learn about stuff and better
>> understand the pros/cons of approaches. It's possible some of the
>> changes will impact the characteristics, but I doubt it can change the
>> fundamental differences due to the simple approach being limited to a
>> single leaf page, etc.
> 
> I think that we're all now agreed that we want to take the complex
> patch's approach. ISTM that that development makes comparative
> benchmarking much less interesting, at least for the time being. IMV
> we should focus on cleaning up the complex patch, and on closing out
> at least a few open items.
> 

I agree comparing "simple" and "complex" patches is less interesting. I
still plan to keep comparing "master" and "complex", mostly to look for
unexpected regressions etc.

> The main thing that I'm personally interested in right now,
> benchmark-wise, is cases where the complex patch doesn't perform as
> well as expected when we compare (say) backwards scans to forwards
> scans with the complex patch. In other words, I'm mostly interested in
> getting an overall sense of the performance profile of the complex
> patch -- which has nothing to do with how it performs against the
> master branch. I'd like to find and debug any weird performance
> bugs/strange discontinuities in performance. I have a feeling that
> there are at least a couple of those lurking in the complex patch
> right now. Once we have some confidence that the overall performance
> profile of the complex patch "makes sense", we can do more invasive
> refactoring (while systematically avoiding new regressions for the
> cases that were fixed).
> 

I can do some tests with forward vs. backwards scans. Of course, the
trouble with finding these weird cases is that they may be fairly rare.
So hitting them is a matter or luck or just happening to generate the
right data / query. But I'll give it a try and we'll see.

> In summary, I think that we should focus on fixing smaller open items
> for now -- with an emphasis on fixing strange inconsistencies in
> performance for distinct-though-similar queries (pairs of queries that
> intuitively seem like they should perform very similarly, but somehow
> have very different performance). I can't really justify that, but my
> gut feeling is that that's the best place to focus our efforts for the
> time being.
> 

OK

-- 
Tomas Vondra