On Thu, 18 Jul 2019 at 14:30, Andres Freund <andres@anarazel.de> wrote:
> I think the AM part of this patch might be the wrong approach - it won't
> do anything meaningful for an AM that doesn't directly map the ctid to a
> specific location in a block (e.g. zedstore). To me it seems the
> callback ought to be to get a range of tids, and the tidrange scan
> shouldn't do anything but determine the range of tids the AM should
> return.
Sounds like that's going to require adding some new fields to
HeapScanDescData, then some callback similar to heap_setscanlimits to
set those fields.
Then, we'd either need to:
1. Make the table_scan_getnextslot() implementations check the tuple
falls within the range, or
2. add another callback that pays attention to the set TID range.
The problem with #1 is that would add overhead to normal seqscans,
which seems like a bad idea.
Did you imagined two additional callbacks, 1 to set the TID range,
then one to scan it? Duplicating the logic in heapgettup_pagemode()
and heapgettup() looks pretty horrible, but I guess we could add a
wrapper around it that loops until it gets the first tuple and bails
once it scans beyond the final tuple.
Is that what you had in mind?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
