Re: [HACKERS] Hash vs. HashJoin nodes

2005-04-16 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > Hmm, true. Perhaps then just hacking the hash node so that hash join > pulls on it twice (the first time for a single tuple, the second time > for the rest) is the way to go. Since the hash node is essentially an > implementation detail of hash join, I d

Re: [HACKERS] Hash vs. HashJoin nodes

2005-03-31 Thread Jim C. Nasby
On Thu, Mar 31, 2005 at 12:03:37AM -0500, Tom Lane wrote: > > Right; I was planning to bail and only do this for inner joins. > > Well, for outer joins the optimal strategy is simple: pull from the > outer query first. If it's empty then you needn't touch the inner > query at all. Otherwise you

Re: [HACKERS] Hash vs. HashJoin nodes

2005-03-30 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > I think this tweak would be universally better than the existing code. Yes, but you miss the point: there's a case where the existing code isn't good and you aren't improving it. Specifically, where the inner query has high startup cost and the outer quer

Re: [HACKERS] Hash vs. HashJoin nodes

2005-03-30 Thread Neil Conway
Tom Lane wrote: One small objection is that we'd lose the ability to separately display the time spent building the hash table in EXPLAIN ANALYZE output. It's probably not super important, but might be a reason to keep two plan nodes in the tree. Hmm, true. Perhaps then just hacking the hash node

Re: [HACKERS] Hash vs. HashJoin nodes

2005-03-30 Thread Christopher Kings-Lynne
One small objection is that we'd lose the ability to separately display the time spent building the hash table in EXPLAIN ANALYZE output. It's probably not super important, but might be a reason to keep two plan nodes in the tree. Would a separate hash node help for these kinds of queries in the f

Re: [HACKERS] Hash vs. HashJoin nodes

2005-03-30 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > ... I'm wondering if there is any value to maintaining the hash > vs. hash join distinction in the first place.) One small objection is that we'd lose the ability to separately display the time spent building the hash table in EXPLAIN ANALYZE output. It's

[HACKERS] Hash vs. HashJoin nodes

2005-03-30 Thread Neil Conway
Is there a reason why the implementation of hash joins uses a separate "hash" child node? AFAICS that node is only used in hash joins. Perhaps the intent was to be able to provide a generic "hashing" capability that could be used by any part of the executor that needs to hash tuples, but AFAICS