Re: Recent 7.4 change slowed down a query by a factor of 3
От | Bruno Wolff III |
---|---|
Тема | Re: Recent 7.4 change slowed down a query by a factor of 3 |
Дата | |
Msg-id | 20030618155340.GA21222@wolff.to обсуждение исходный текст |
Ответ на | Re: Recent 7.4 change slowed down a query by a factor of 3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recent 7.4 change slowed down a query by a factor of 3
|
Список | pgsql-performance |
On Wed, Jun 18, 2003 at 11:18:39 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruno Wolff III <bruno@wolff.to> writes: > > The query below was running in a bit under 300ms on a version of 7.4 > > from less than a week ago until I updated to the version from last night. > > Now it takes about 800ms using a significantly different plan. > > Something fishy here. Will it use the right plan if you set > enable_seqscan off? After doing an initdb I got the expected plan. This is a static db used for dynamic web pages and the script that loads the db does a vacumm analyze at the end. So the db should have had the information needed to pick the correct plan. Possibly something changed that affected the information needed for planning, but the value used to indicate an initdb was needed wasn't changed. In the future if I see odd stuff I will try doing an initdb before reporting a potential problem. Thanks for your help.
В списке pgsql-performance по дате отправления: