Re: strange query execution times

On Tue, 2001-10-02 at 17:49, Tom Lane wrote:
> Markus Bertheau <twanger@bluetwanger.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