Re: Tid scan improvements

Edmund Horner <ejrh00@gmail.com>

From: Edmund Horner <ejrh00@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-07-22T07:44:49Z
Lists: pgsql-hackers
On Mon, 22 Jul 2019 at 19:25, David Rowley <david.rowley@2ndquadrant.com>
> On Sat, 20 Jul 2019 at 06:21, Andres Freund <andres@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



Commits

  1. Add TID Range Scans to support efficient scanning ranges of TIDs

  2. Improve planner's selectivity estimates for inequalities on CTID.