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_aZUr6N4DSvaXdWkfeV=1gN-jTodgh7Cd3r7=QV5_QZtg@mail.gmail.com
Whole thread Raw
In response to Re: Streaming read-ready sequential scan code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Feb 20, 2024 at 6:13 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Feb 20, 2024 at 4:35 AM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> > I've written three alternative implementations of the actual streaming
> > read user for sequential scan which handle the question of where to
> > allocate the streaming read object and how to handle changing scan
> > direction in different ways.
>
> It's weird to me that the prospect of changing the scan direction
> causes such complexity. I mean, why doesn't a streaming read object
> have a forget_all_my_previous_requests() method or somesuch?

Basically, that is what pg_streaming_read_free() does. It goes through
and releases the buffers it had pinned and frees any per-buffer data
allocated.

The complexity with the sequential scan streaming read user and scan
direction is just that it has to detect when the scan direction
changes and do the releasing/freeing and reallocation. The scan
direction is passed to heapgettup[_pagemode](), so this is something
that can change on a tuple-to-tuple basis.

It is less that doing this is complicated and more that it is annoying
and distracting to have to check for and handle a very unimportant and
uncommon case in the main path of the common case.

- Melanie



pgsql-hackers by date:

Previous
From: Ilyasov Ian
Date:
Subject: RE: Integer undeflow in fprintf in dsa.c
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add lookup table for replication slot invalidation causes