Re: Streaming read-ready sequential scan code

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: Streaming read-ready sequential scan code
Дата
Msg-id CAAKRu_aJXnqsyZt6HwFLnxYEBgE17oypkxbKbT1t1geE_wvH2Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Streaming read-ready sequential scan code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Streaming read-ready sequential scan code  (Thomas Munro <thomas.munro@gmail.com>)
Re: Streaming read-ready sequential scan code  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
On Tue, Apr 2, 2024 at 1:10 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 01/04/2024 22:58, Melanie Plageman wrote:
> > Attached v7 has version 14 of the streaming read API as well as a few
> > small tweaks to comments and code.
>
> I saw benchmarks in this thread to show that there's no regression when
> the data is in cache, but I didn't see any benchmarks demonstrating the
> benefit of this. So I ran this quick test:

Good point! It would be good to show why we would actually want this
patch. Attached v8 is rebased over current master (which now has the
streaming read API).

On the topic of BAS_BULKREAD buffer access strategy, I think the least
we could do is add an assert like this to read_stream_begin_relation()
after calculating max_pinned_buffers.

    Assert(GetAccessStrategyBufferCount(strategy) > max_pinned_buffers);

Perhaps we should do more? I think with a ring size of 16 MB, large
SELECTs are safe for now. But I know future developers will make
changes and it would be good not to assume they will understand that
pinning more buffers than the size of the ring effectively invalidates
the ring.

- Melanie

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Is it safe to cache data by GiST consistent function
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: RFC: Additional Directory for Extensions