Greg Stark writes:
> For the user visible ctid we could just arbitrarily declare that the ctid
> returned by an IOS is the head of the HOT update chain instead of the tail.
No, I don't think that'd work at all, because that tuple might be dead.
A minimum expectation is that "SELECT ... WHERE ctid
For the user visible ctid we could just arbitrarily declare that the ctid
returned by an IOS is the head of the HOT update chain instead of the tail.
It might be a bit confusing when sequential scans return the tail (or
whichever member is visible). But it's not really wrong, all the members of
the
Laurenz Albe writes:
> On Mon, 2020-02-03 at 14:43 -0500, Tom Lane wrote:
>> Laurenz Albe writes:
>>> I noticed that "ctid" in the select list prevents an index only scan:
>>> This strikes me as strange, since every index contains "ctid".
>> There's no provision for an IOS to return a system col
On Mon, 2020-02-03 at 14:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I noticed that "ctid" in the select list prevents an index only scan:
> > This strikes me as strange, since every index contains "ctid".
>
> There's no provision for an IOS to return a system column, though.
> Not sure
Laurenz Albe writes:
> I noticed that "ctid" in the select list prevents an index only scan:
> This strikes me as strange, since every index contains "ctid".
There's no provision for an IOS to return a system column, though.
Not sure what it'd take to make that possible.
I noticed that "ctid" in the select list prevents an index only scan:
CREATE TABLE ios (id bigint NOT NULL, val text NOT NULL);
INSERT INTO ios SELECT i, i::text FROM generate_series(1, 10) AS i;
CREATE INDEX ON ios (id);
VACUUM (ANALYZE) ios;
EXPLAIN (VERBOSE, COSTS off) SELECT ctid, id F
