On Fri, 21 Dec 2018 at 11:21, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Edmund Horner <ejr...@gmail.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.)
