From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming read-ready sequential scan code |
Date: | 2024-04-07 22:12:29 |
Message-ID: | 20240407221229.upgvhyf2gzflcawi@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-04-07 22:15:06 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | David E. Wheeler | 2024-04-07 22:11:32 | Re: ❓ JSON Path Dot Precedence |