Re: Joins on TID
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-12-22T19:15:02Z
Lists: pgsql-hackers
On Sat, 22 Dec 2018 at 16:31, Tom Lane <tgl@sss.pgh.pa.us> wrote: > What I'm thinking about in this thread is joins on TID, which we have only > very weak support for today --- you'll basically always wind up with a > mergejoin, which requires full-table scan and sort of its inputs. Still, > that's better than a naive nestloop, and for years we've been figuring > that that was good enough. Several people in the other thread that > I cited felt that that isn't good enough. But if we think it's worth > taking seriously, then IMO we need to add both parameterized scans (for > nestloop-with-inner-fetch-by-tid) and hash join, because each of those > can dominate depending on how many tuples you're joining. > That would certainly help if you are building a column store, or other new index types. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add a hash opclass for type "tid".
- 0a6ea4001a9d 12.0 landed
-
Support parameterized TidPaths.
- b5415e3c2187 12.0 landed