Tom, thanks for the effort of answering my questions.
I'm a long time reader of this list and you are always very helpfull.
On Sat, Feb 02, 2002 at 03:57:19PM -0500, Tom Lane wrote:
> 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.
OK, I can understand this, but...
> > 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.
Sigh. Then what can be?
Before, a few days back, the 'same' query on the 'slow' database took
approximately the same time on the 'fast' one; it took seconds.
I've never taken the time to study the results of EXPLAIN, because I was
happy with the default actions.
Now, on the 'fast' database is still takes seconds but on the 'slow'
one it takes minutes and the only change I can think of is the added
column.
The database are on the same server, they share the same processor, the
same memory and the same disk.
What can possible be the cause of the difference in preformance?
Is is as simple as a wrong choice of the planner and can a wrong choice
have such huge effect?
> regards, tom lane
Regards,
Cees.
