Re: Streaming read-ready sequential scan code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Streaming read-ready sequential scan code
Date
Msg-id 20240407221229.upgvhyf2gzflcawi@awork3.anarazel.de
Whole thread Raw
In response to Re: Streaming read-ready sequential scan code  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Streaming read-ready sequential scan code
List pgsql-hackers
Hi,

On 2024-04-08 09:36:59 +1200, Thomas Munro wrote:
> I've been on the fence about that flag for sequential scan...  Some
> days I want to consider changing to READ_STREAM_DEFAULT and relying on
> our "anti-heuristics" to suppress advice, which would work out the
> same in most cases but might occasionally win big.

Agreed, it's pretty easy to end up with a fairly "fragmented" set of a
relation's buffers in s_b.  OTOH, there might not be any need for the
heuristic if we actually trigger reads asynchronously.


> BTW looking at the branching in read-stream user patches that have an
> initialisation step like yours, I wonder if it might every make sense
> to be able to change the callback on the fly from inside the callback,
> so that you finish up with a branchless one doing most of the work.  I
> have no idea if it's worth it...

I was wondering about that too, I dislike those branches. But instead of
changing the callback, it seems like a better design would be to have another
dedicated callback for that?  There already is a dedicated branch for the
"just starting up" path in read_stream_next_buffer(), so it'd be pretty much
free to call another callback there.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: ❓ JSON Path Dot Precedence
Next
From: Alexander Korotkov
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands