On Mon, 22 Jul 2019 at 19:25, David Rowley <david.row...@2ndquadrant.com> > On Sat, 20 Jul 2019 at 06:21, Andres Freund <and...@anarazel.de> wrote: > > Yea, I was thinking of something like 2. We already have a few extra > > types of scan nodes (bitmap heap and sample scan), it'd not be bad to > > add another. And as you say, they can just share most of the guts: For > > heap I'd just implement pagemode, and perhaps split heapgettup_pagemode > > into two parts (one to do the page processing, the other to determine > > the relevant page). > > > > You say that we'd need new fields in HeapScanDescData - not so sure > > about that, it seems feasible to just provide the boundaries in the > > call? But I think it'd also just be fine to have the additional fields. > > Thanks for explaining. > > I've set the CF entry for the patch back to waiting on author. > > I think if we get this part the way Andres would like it, then we're > pretty close.
I've moved the code in question into heapam, with: * a new scan type SO_TYPE_TIDRANGE (renumbering some of the other enums). * a wrapper table_beginscan_tidrange(Relation rel, Snapshot snapshot); I'm not sure whether we need scankeys and the other flags? * a new optional callback scan_settidrange(TableScanDesc scan, ItemPointer startTid, ItemPointer endTid) with wrapper table_scan_settidrange. I thought about combining it with table_beginscan_tidrange but we're not really doing that with any of the other beginscan methods. * another optional callback scan_getnexttidrangeslot. The presence of these two callbacks indicates that TidRangeScan is supported for this relation. Let me know if you can think of better names. However, the heap_getnexttidrangeslot function is just the same iterative code calling heap_getnextslot and checking the tuples against the tid range (two fields added to the ScanDesc). I'll have to spend a bit of time looking at heapgettup_pagemode to figure how to split it as Andres suggests. Thanks, Edmund