Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 73C819FBA99 for ; Mon, 25 Jun 2007 19:10:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 57236-07 for ; Mon, 25 Jun 2007 19:10:18 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 718AD9FB958 for ; Mon, 25 Jun 2007 19:10:18 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l5PMAFWp007009; Mon, 25 Jun 2007 18:10:15 -0400 (EDT) To: "Tyrrill, Ed" cc: pgsql-performance@postgresql.org Subject: Re: In-reply-to: References: Comments: In-reply-to "Tyrrill, Ed" message dated "Mon, 25 Jun 2007 14:28:32 -0700" Date: Mon, 25 Jun 2007 18:10:15 -0400 Message-ID: <7008.1182809415@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/588 X-Sequence-Number: 25621 "Tyrrill, Ed" writes: > ... With 8.2.4.1 I get the same plan and performance with > default_statistics_target set to either 10 or 100: There's something fishy about that, because AFAICS from the CVS logs, there are no relevant planner changes between 8.2.3 and 8.2.4. You should have gotten exactly the same behavior with both. Maybe the version difference you think you see is due to noise in ANALYZE's random sampling --- are the plan choices stable if you repeat ANALYZE several times at the same statistics target? I'm also noticing some rather large variation in what ought to be essentially the same seqscan cost: > -> Seq Scan on backup_location (cost=0.00..3520915.44 > rows=215090944 width=8) (actual time=0.048..333944.886 rows=215090786 > loops=1) > -> Seq Scan on backup_location (cost=0.00..3520915.44 > rows=215090944 width=8) (actual time=17.905..790499.303 rows=215090786 > loops=1) > -> Seq Scan on backup_location (cost=0.00..3520915.44 > rows=215090944 width=8) (actual time=7.110..246561.900 rows=215090786 > loops=1) Got any idea what's up with that --- heavy background activity maybe, or partially cached table data? It's pretty tough to blame the plan for a 3x variation in the cost of reading data. Also, what do you have work_mem set to? Have you changed any of the planner cost parameters from their defaults? regards, tom lane