From: | Edmund Horner <ejrh00(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Tid scan improvements |
Date: | 2019-07-22 07:44:49 |
Message-ID: | CAMyN-kBvFNDO2LSRg0xPzKU1PKMurW6PZ8gWJ2gMwgG1dkhs-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 22 Jul 2019 at 19:25, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
> On Sat, 20 Jul 2019 at 06:21, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peifeng Qiu | 2019-07-22 08:01:46 | Re: Compile from source using latest Microsoft Windows SDK |
Previous Message | Michael Paquier | 2019-07-22 07:36:00 | Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ ) |