X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 8E376528FF for ; Thu, 9 Jun 2005 05:50:18 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 05225-10 for ; Thu, 9 Jun 2005 08:50:09 +0000 (GMT) Received: from oismail.com (unknown [38.117.22.100]) by svr1.postgresql.org (Postfix) with ESMTP id 94F7952867 for ; Thu, 9 Jun 2005 05:50:08 -0300 (ADT) Received: from [192.168.8.103] ([213.173.234.215]) (authenticated bits=0) by oismail.com (8.12.11/8.12.11) with ESMTP id j598o0f5012484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jun 2005 04:50:02 -0400 Message-ID: <42A803C8.6070507@oismail.com> Date: Thu, 09 Jun 2005 10:54:32 +0200 From: Jona User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Kings-Lynne Cc: Dennis Bjorklund , pgsql-performance@postgresql.org Subject: Re: Query plan changes after pg_dump / pg_restore References: <42A7F9D9.8000004@oismail.com> <42A7FD12.2080608@familyhealth.com.au> In-Reply-To: <42A7FD12.2080608@familyhealth.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.112 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/204 X-Sequence-Number: 12841 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