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
The path field is an "ltree" column, with an GIST index on it.
Something to do with bitmap indexscans on lossy indexes?
Chris
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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
16 matches
Mail list logo
