Tom Lane wrote:
>
> It wouldn't be hard that I can see (just build hash and btree opclasses
> for tid), but I'm pretty unclear on why bother. There's no use-case for
> cross-table joins involving ctid, since you couldn't usefully store a
> ctid referencing another table. The example Ilja showed was quite
> artificial and should not convince anyone to expend effort on this.
> Perhaps there are more convincing examples, but let's see one.
Would it be useful for extremely static (read-only) data?
The largest tables in my database are read-only for many months
at a time (geospatial data which the vendor updates annually).
I've occasionally wondered if storing ctids in tables that link
to these tables rather than the traditional id column would help.
(I never really bothered, though; since normal index scans were
fast enough; and any future performance optimization will probably
cache this data in memcached instead.)