Re: Query plan changes after pg_dump / pg_restore
| От | Jona |
|---|---|
| Тема | Re: Query plan changes after pg_dump / pg_restore |
| Дата | |
| Msg-id | 42A803C8.6070507@oismail.com обсуждение исходный текст |
| Ответ на | Re: Query plan changes after pg_dump / pg_restore (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
| Ответы |
Re: Query plan changes after pg_dump / pg_restore
|
| Список | pgsql-performance |
Thanks... have notified our sys admin of that so he can make the correct changes. It still doesn't explain the difference in query plans though? I mean, it's the same database server the two instances of the same database is running on. One instance (the live) just insists on doing the seq scan of the 50k records in Price_Tbl and the 6.5k records in SCT2SubCatType_Tbl. Seems weird.... Cheers Jona Christopher Kings-Lynne wrote: >> Thank you for the swift reply, the following is the output of the >> SHOW ALL for shared_buffers and effective_cache_size. >> shared_buffers: 13384 >> effective_cache_size: 4000 >> server memory: 2GB > > > effective_cache_size should be 10-100x larger perhaps... > > Chris
В списке pgsql-performance по дате отправления: