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