Re: Preformance
От | Cees van de Griend |
---|---|
Тема | Re: Preformance |
Дата | |
Msg-id | 20020203131004.A14012@griend.xs4all.nl обсуждение исходный текст |
Ответ на | Re: Preformance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Preformance
|
Список | pgsql-general |
On Sat, Feb 02, 2002 at 05:09:58PM -0500, Tom Lane wrote: > Cees van de Griend <cees-list@griend.xs4all.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.
В списке pgsql-general по дате отправления: