]> granicus.if.org Git - postgresql/commit
Add a hash opclass for type "tid".
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 30 Dec 2018 20:40:04 +0000 (15:40 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 30 Dec 2018 20:40:04 +0000 (15:40 -0500)
commit0a6ea4001a9dff64e9ba66f68855a59a1bf69bc9
tree7ab069dcd37ad075745f99b3e9d56b191c4cd19a
parentb5415e3c2187ab304390524f5ae66b4bd2c58279
Add a hash opclass for type "tid".

Up to now we've not worried much about joins where the join key is a
relation's CTID column, reasoning that storing a table's CTIDs in some
other table would be pretty useless.  However, there are use-cases for
this sort of query involving self-joins, so that argument doesn't really
hold water.

With larger relations, a merge or hash join is desirable.  We had a btree
opclass for type "tid", allowing merge joins on CTID, but no hash opclass
so that hash joins weren't possible.  Add the missing infrastructure.

This also potentially enables hash aggregation on "tid", though the
use-cases for that aren't too clear.

Discussion: https://postgr.es/m/1853.1545453106@sss.pgh.pa.us
src/backend/utils/adt/tid.c
src/include/catalog/catversion.h
src/include/catalog/pg_amop.dat
src/include/catalog/pg_amproc.dat
src/include/catalog/pg_opclass.dat
src/include/catalog/pg_operator.dat
src/include/catalog/pg_opfamily.dat
src/include/catalog/pg_proc.dat
src/test/regress/expected/tidscan.out
src/test/regress/sql/tidscan.sql