Re: Tid scan improvements

On Fri, 21 Dec 2018 at 11:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Edmund Horner <ejrh00(at)gmail(dot)com> writes:
> > [ tid scan patches ]
>
> I'm having a hard time wrapping my mind around why you'd bother with
> backwards TID scans. The amount of code needed versus the amount of
> usefulness seems like a pretty bad cost/benefit ratio, IMO. I can
> see that there might be value in knowing that a regular scan has
> "ORDER BY ctid ASC" pathkeys (mainly, that it might let us mergejoin
> on TID without an explicit sort). It does not, however, follow that
> there's any additional value in supporting the DESC case.

I have occasionally found myself running "SELECT MAX(ctid) FROM t"
when I was curious about why a table is so big after vacuuming.

Perhaps that's not a common enough use case to justify the amount of
code, especially the changes to heapam.c and explain.c.

We'd still need the pathkeys to make good use of forward scans. (And
I think the executor still needs to support seeking backward for
cursors.)