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.) ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
