Date: Mon, 23 Jun 2014 17:39:47 -0700 (PDT)
From: tim_wilson <tim.wilson@telogis.com>
To: pgsql-performance@postgresql.org
Message-ID: <1403570387738-5808509.post@n5.nabble.com>
In-Reply-To: <1402440085834-5806747.post@n5.nabble.com>
References: <1400459729388-5804416.post@n5.nabble.com>
 <11299.1400559202@sss.pgh.pa.us> <1402016119875-5806283.post@n5.nabble.com>
 <1402037012706-5806302.post@n5.nabble.com>
 <1402053752755-5806320.post@n5.nabble.com>
 <1402436240210-5806743.post@n5.nabble.com> <6448.1402438054@sss.pgh.pa.us>
 <1402440085834-5806747.post@n5.nabble.com>
Subject: Re: autovacuum vacuum creates bad statistics for planner when it
 log index scans: 0
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Have been looking at lazyvacuum.c trying to think of a way of changing the
calculation of the stats to ensure that my hot table stats do not get so
badly distorted.

What I have noticed is that when I reindex my hot table the stats on the
table do not seem to change in pg_stat_user_tables (ie they stay bad) but
the EXPLAIN for the query starts using the correct index again. 

The index itself does not seem very bloated but reindex seems to alter the
query optimizer choices. I can't see in index.c where side effect would be
caused.

Why is this? Not sure if this is entirely helpful as reindex takes exclusive
lock, but if I used a concurrent rebuild and rename of the index I might be
able to work around this.


--
View this message in context: http://postgresql.1045698.n5.nabble.com/autovacuum-vacuum-creates-bad-statistics-for-planner-when-it-log-index-scans-0-tp5804416p5808509.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance