Re: Query plan changes after pg_dump / pg_restore - Mailing list pgsql-performance

From Jona
Subject Re: Query plan changes after pg_dump / pg_restore
Date
Msg-id 42A803C8.6070507@oismail.com
Whole thread Raw
In response to Re: Query plan changes after pg_dump / pg_restore  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Query plan changes after pg_dump / pg_restore
List 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 by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Query plan changes after pg_dump / pg_restore
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Query plan changes after pg_dump / pg_restore