Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tm4cI-00058m-1y for pgsql-performance@arkaria.postgresql.org; Fri, 21 Dec 2012 15:34:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Tm4cG-0004iJ-UI for pgsql-performance@arkaria.postgresql.org; Fri, 21 Dec 2012 15:34:28 +0000 Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tm4c5-0004YF-Eo for pgsql-performance@postgresql.org; Fri, 21 Dec 2012 15:34:17 +0000 Received: from mout.gmx.net ([74.208.4.200]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tm4c3-0005Vd-9v for pgsql-performance@postgresql.org; Fri, 21 Dec 2012 15:34:16 +0000 Received: from mailout-us.gmx.com ([172.19.198.41]) by mrigmx.server.lan (mrigmxus002) with ESMTP (Nemesis) id 0MAeGl-1TxwRK4ATT-00Bw8y for ; Fri, 21 Dec 2012 16:34:14 +0100 Received: (qmail 19935 invoked by uid 0); 21 Dec 2012 15:34:13 -0000 Received: from 76.255.19.161 by rms-us017 with HTTP Cc: pgsql-performance@postgresql.org Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 10:34:13 -0500 From: "Kevin Grittner" Message-ID: <20121221153413.144660@gmx.com> MIME-Version: 1.0 Subject: Re: Slow queries after vacuum analyze To: "Ghislain ROUVIGNAC" X-Authenticated: #138763884 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: IuSmcOZZ3zOlOQ09LnwhcRx+IGRvb4DZ X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Ghislain ROUVIGNAC wrote: >> I would leave default_statistics_target alone unless you see a lot of >> estimates which are off by more than an order of magnitude. Even then, it >> is often better to set a higher value for a few individual columns than for >> everything. > > > We had an issue with a customer where we had to increase the statistics > parameter for a primary key. > So I'd like to know if there is a way to identify for which column we have > to change the statistics. I don't know a better way than to investigate queries which seem to be running longer than you would expect, and look for cases where EXPLAIN ANALYZE shows an estimated row count which is off from actual by enough to cause a problem. Sometimes this is caused by correlations between values in different columns, in which case a higher target is not likely to help; but sometimes it's a matter that there is an uneven distribution among values not included in the "most common values", in which case boosting the target to store more values and finer-grained information on ranges will be exactly what you need. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance