From: | Cees van de Griend <cees-list(at)griend(dot)xs4all(dot)nl> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Preformance |
Date: | 2002-02-03 12:10:04 |
Message-ID: | 20020203131004.A14012@griend.xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Feb 02, 2002 at 05:09:58PM -0500, Tom Lane wrote:
> Cees van de Griend <cees-list(at)griend(dot)xs4all(dot)nl> writes:
> > What can possible be the cause of the difference in preformance?
>
> Probably the VACUUM ANALYZE statistics changed just enough to push the
> planner into making the wrong choice. You could experiment with doing
> "set enable_nestloop to off" and then EXPLAIN to see what the plan and
> cost are; I'll bet that the estimated cost of the hash plan is now
> just fractionally more than that of the nestloop.
>
> Of course, the *true* costs are very different, which is why I consider
> this a planner estimation failure.
I have dumped the table, droped the table and put the dump back into the
database. Now the speed is as it should be (for the time being).
If I understand you explanation, a possible hack to circumvent this problem
could be to trick the planner into thinking that it should use the hash
scan method, by inserting dummy data into the tbl[XXX]Number.
Another possible fix is to execute 'SET enable_nestloop = OFF;' before every
query.
Is this correct?
> regards, tom lane
Regards,
Cees.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-02-03 16:43:00 | Re: Preformance |
Previous Message | Jeff Martin | 2002-02-03 04:51:04 | Re: PostgreSQL transaction locking problem |