Cees van de Griend <cees@griend.xs4all.nl> writes:
>> The problem is presumably that the planner is drastically
>> underestimating the number of joinable rows in "dn" in the
>> second case, and so choosing a plan that works well if that
>> number is small but not well when it's large.
> This is the strange part. The sizes of the 2 databases are not that
> great and the 'fast' one has a bigger Number table:
Nothing strange about that. The larger table is probably enough
larger to persuade the planner to take the hash-join plan; remember
the problem in the other case is that the planner thinks there are few
enough rows to make nestloop appropriate, when there really are too
many for that plan to be a good choice.
> Someone has altered the table and added a column which is never used,
> there is no data in it and it is never used in a query.
> Can this be the reason for the huge preformance loss?
No.
regards, tom lane
