Re: Index only scan and 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 chain are equally valid answers.

For a data modifying query -- and it would have to be one targeting some
other table or else there's no way it could be an IOS -- does having a ctid
for the head rather than the tail still work? I'm not clear how EPQ works
for such cases. Does it still do an index scan at all or does it just do a
ctid scan? And does it follow HOT update chains if the row was updated?

On Tue., Feb. 4, 2020, 13:23 Tom Lane, <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Mon, 2020-02-03 at 14:43 -0500, Tom Lane wrote:
> >> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 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 was reminded what the obvious problem is:
> > the ctid of a heap only tuple is not stored in the index. Duh.
>
> Duh ... the members of a HOT chain share the same indexed value(s),
> which is why we needn't care exactly which one is live during IOS.
> But they don't have the same TID. Oh well.
>
> regards, tom lane
>
>
>