Tom Lane <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> So the use case of a real block nested loop would be doing a cartesian join >> of >> two large tables where neither fits in RAM. That does seem like it might be >> kind of narrow given how large the output would be. > > Yeah. If you have a hashable join condition then our existing batched > hash join code should be roughly equivalent to this method. So the use > case is joining a couple of large tables with an un-hashable, > un-indexable join condition (or none at all, ie cross product) and that > just isn't something we hear people wanting to do a lot. I can't really > see why we'd bother maintaining extra code for block nested loop.
Hm, I hadn't thought of other non-hashable join conditions. I wonder how much code it would be though if we just hacked hash join to support returning the full cartesian product. Ie, instead of doing a hash lookup do a full scan of the hash and recheck the join condition if any for every combination. That seems like it would be a pretty small change to HashJoin and would effectively support precisely this join type. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
