Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-29 Thread Mario Weilguni
Am Dienstag, 29. November 2005 10:05 schrieb Mario Weilguni: > Hello Tom, > > I tried both patches on a different machine (but had to take the patches > from cvs diff, cut'n paste from the mail-program did not work). Up until > now, they work like a charm, correct results and fast. I will try on th

Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-29 Thread Mario Weilguni
ql-hackers@postgresql.org Subject: Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off) I wrote: > For a query like this, where the hash join is being done repeatedly, > it might be useful for the executor itself to track how often each &g

Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-28 Thread Greg Stark
Tom Lane <[EMAIL PROTECTED]> writes: > In particular, the executor knows that the outer subplan is parameterless > and therefore should deliver the same results each time (modulo volatile > functions of course), so after the first cycle it could know that there's no > point in trying the early fe

Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-28 Thread Tom Lane
Greg Stark <[EMAIL PROTECTED]> writes: > I suspect this is obvious but since you asked, there isn't any way to keep > around the hash table and just reuse it repeatedly instead of having to rescan > the data over and over is there? We already do that when possible --- which it's not in the particu

Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-28 Thread Tom Lane
I wrote: > For a query like this, where the hash join is being done repeatedly, > it might be useful for the executor itself to track how often each > subplan has been seen to be empty. I implemented a simple form of this, and it made 8.1 faster than 8.0 on the test case I was using. Give it a tr

Re: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-28 Thread Mario Weilguni
Title: AW: Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off) If the query runs slow it will be not such a problem, but I was very concerned about other queries having this problem too - without knowing it. I've already rewritte

Hashjoin startup strategy (was Re: [HACKERS] Getting different number of results when using hashjoin on/off)

2005-11-28 Thread Tom Lane
"Mario Weilguni" <[EMAIL PROTECTED]> writes: > Thanks for the quick response, I've tried the patch, but it did not work > as expected. When I set enable_hashjoin to off, everything works as > expected, but with hashjoin on I do not even get results anymore, CPU is > going up to 100% and after 3 min