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

From Melanie Plageman
Subject Re: Streaming read-ready sequential scan code
Date
Msg-id CAAKRu_aJXnqsyZt6HwFLnxYEBgE17oypkxbKbT1t1geE_wvH2Q@mail.gmail.com
Whole thread Raw
In response to Re: Streaming read-ready sequential scan code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Streaming read-ready sequential scan code
Re: Streaming read-ready sequential scan code
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is it safe to cache data by GiST consistent function
Next
From: Christoph Berg
Date:
Subject: Re: RFC: Additional Directory for Extensions