Re: Tid scan improvements - Mailing list pgsql-hackers

From David Rowley
Subject Re: Tid scan improvements
Date
Msg-id CAApHDvqDcx3_CM1Y4hiCv7q3o3iLFsF1g=SQ5B=6NJoSPEDA_Q@mail.gmail.com
Whole thread Raw
In response to Re: Tid scan improvements  (Andres Freund <andres@anarazel.de>)
Responses Re: Tid scan improvements
List pgsql-hackers
Thanks for looking at this.

On Thu, 4 Feb 2021 at 10:19, Andres Freund <andres@anarazel.de> wrote:
> Perhaps something like
>
> typedef struct TableScanTidRange TableScanTidRange;
>
> TableScanTidRange* table_scan_tid_range_start(TableScanDesc sscan, ItemPointer mintid, ItemPointer maxtid);
> bool table_scan_tid_range_nextslot(TableScanDesc sscan, TableScanTidRange *range, TupleTableSlot *slot);
> void table_scan_tid_range_end(TableScanDesc sscan, TableScanTidRange* range);
>
> would work better? That'd allow an AM to have arbitrarily large state
> for a tid range scan, would make it clear what the lifetime of the
> ItemPointer mintid, ItemPointer maxtid are etc.  Wouldn't, on the API
> level, prevent multiple tid range scans from being in progress at the
> same times though :(. Perhaps we could add a TableScanTidRange* pointer
> to TableScanDesc which'd be checked/set by tableam.h which'd prevent that?

Maybe the TableScanTidRange can just have a field to store the
TableScanDesc. That way table_scan_tid_range_nextslot and
table_scan_tid_range_end can just pass the TableScanTidRange pointer.

That way it seems like it would be ok for multiple scans to be going
on concurrently as nobody should be reusing the TableScanDesc.

Does that seem ok?

David



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Tid scan improvements
Next
From: Tom Lane
Date:
Subject: Re: Can we have a new SQL callable function to get Postmaster PID?