Re: Streaming read-ready sequential scan code

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Streaming read-ready sequential scan code
Дата
Msg-id 20240407221229.upgvhyf2gzflcawi@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Streaming read-ready sequential scan code  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Streaming read-ready sequential scan code
Список 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 по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: ❓ JSON Path Dot Precedence
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands