Re: strange query execution times

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 ...

regards, tom lane