On Tue, 2001-10-02 at 17:49, Tom Lane wrote: > Markus Bertheau <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
