> 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
