> But why? Is there a way to force the planner into this? I don't know enough about the planner to answer the "why", but the root of the problem seems to be the mis-estimate for the join between test_result and recipe_version (1348 instead of 21983 rows). That makes the planner think that a nested loop join would be cheaper, but it really is not. I had hoped that improving statistics would improve that estimate. The only way to force the planner to do it that way is to set enable_nestloop=off, but only for that one query. And even that is a bad idea, because for different constant values or when the table data change, a nested loop join might actually be the best choice. I don't know how to solve that problem. Yours, Laurenz Albe -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
