From: | Markus Bertheau <twanger(at)bluetwanger(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | postgres sql list <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: strange query execution times |
Date: | 2001-10-05 06:48:57 |
Message-ID: | 1002264548.15228.1.camel@entwicklung01.cenes.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Tue, 2001-10-02 at 17:49, Tom Lane wrote:
> Markus Bertheau <twanger(at)bluetwanger(dot)de> writes:
> > r_kunden_anbieter describes the relationship between customers and
> > suppliers. there are five status, 0 to 4 in attribute beziehung. both
> > queries return the same results. they select all customers which have a
> > certain relationship (beziehung = 3) to a given supplier.
> > personen has 484 rows, r_kunden_anbieter 327.
>
> How many rows actually satisfy "rka.a_id = 620 and rka.beziehung = 3"?
>
> The issue appears to be that the planner estimates one matching row
> in the one case and two matching rows in the second. Given the estimate
> of one row, it decides to go for the low-overhead nested loop plan.
> I am guessing that there are really considerably more than two matching
> rows, and so the nested loop plan loses badly compared to the mergejoin,
> which takes longer to set up but is better able to cope with many rows.
>
> FWIW, 7.2 has better statistics and should be better able to pick the
> right plan in this context ...
13 rows do. Is there a way to force 7.0.3 (or 7.1.3) to use the
mergejoin with the straightforward condition?
Markus Bertheau
Cenes Data GmbH
From | Date | Subject | |
---|---|---|---|
Next Message | Janning Vygen | 2001-10-05 10:39:40 | Problem with n to n relation |
Previous Message | Josh Berkus | 2001-10-05 01:01:54 | Re: Alias Join Table |