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
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
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
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
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
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
"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
Yes. This is from a 8.0.3 (with slightly older and different data,
resulting in only 9 rows, but the rest is the same):
Index Scan using ben_uk3 on foo1 ben (cost=0.00..73867.23 rows=863
width=27) (actual time=38.591..501.839 rows=9 loops=1)
Filter: (subplan)
SubPlan
-> Hash Join (c
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Getting different number of results when using
hashjoin on/off
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> No, I'm using 8.1.0, and tried it on different machines, always the
same results.
I see it, I think: the recent chan
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> No, I'm using 8.1.0, and tried it on different machines, always the same
> results.
I see it, I think: the recent changes to avoid work when one or the
other side of the hash join is empty would exit the hash join leaving
a state that confused ExecRe
ckers@postgresql.org
Subject: Re: [HACKERS] Getting different number of results when using hashjoin
on/off
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> Yes. This is from a 8.0.3 (with slightly older and different data,
> resulting in only 9 rows, but the rest is the sa
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> Yes. This is from a 8.0.3 (with slightly older and different data,
> resulting in only 9 rows, but the rest is the same):
Yeah, that looks more reasonable.
I tried to reproduce this, without any luck:
regression=# explain analyze select count(*) fro
Mario Weilguni <[EMAIL PROTECTED]> writes:
> The failing case is:
> ...
>SubPlan
> -> Hash Join (cost=8.47..19.46 rows=1 width=0) (actual
> time=0.004..0.004 rows=0 loops=21619)
>Hash Cond: ("outer".id = "inner".str_id)
>-> Bitmap Heap Scan on structure str (co
Am Montag, 28. November 2005 14:12 schrieb Christopher Kings-Lynne:
> > The path field is an "ltree" column, with an GIST index on it.
>
> Something to do with bitmap indexscans on lossy indexes?
>
> Chris
I doubt that, "set enable_bitmapscan to off" produces the wrong result as
well.
Best regar
I've a problem that might be a bug in the core system (hashjoins) or with ltree
using gist-index, but I fail miserable to produce a useful testcase (using 8.1,
worked in 8.0):
A query produces wrong (=0) results, when a different plan is enforced, I get a
merge-join plan that looks similar, but
15 matches
Mail list logo
