You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Up to now we've not worried much about joins where the join key is arelation's CTID column, reasoning that storing a table's CTIDs in someother table would be pretty useless. However, there are use-cases forthis sort of query involving self-joins, so that argument doesn't reallyhold water.With larger relations, a merge or hash join is desirable. We had a btreeopclass for type "tid", allowing merge joins on CTID, but no hash opclassso that hash joins weren't possible. Add the missing infrastructure.This also potentially enables hash aggregation on "tid", though theuse-cases for that aren't too clear.Discussion:https://postgr.es/m/1853.1545453106@sss.pgh.pa.us