Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vx1IX-00018y-U1 for pgsql-performance@arkaria.postgresql.org; Sat, 28 Dec 2013 21:19:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vx1IX-00068R-5i for pgsql-performance@arkaria.postgresql.org; Sat, 28 Dec 2013 21:19:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vx1IV-00068I-09 for pgsql-performance@postgresql.org; Sat, 28 Dec 2013 21:19:51 +0000 Received: from mbx.knossos.net.nz ([202.160.48.10]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vx1IK-00053a-VK for pgsql-performance@postgresql.org; Sat, 28 Dec 2013 21:19:50 +0000 Received: from [10.1.1.3] (60-234-150-59.bitstream.orcon.net.nz [60.234.150.59]) (authenticated bits=0) by mbx.knossos.net.nz (8.14.4/8.14.4) with ESMTP id rBSLJK93003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Dec 2013 10:19:27 +1300 Message-ID: <52BF4058.6000306@archidevsys.co.nz> Date: Sun, 29 Dec 2013 10:19:20 +1300 From: Gavin Flower Organization: ArchiDevSys User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kevin Grittner , Michael Kolomeitsev , "pgsql-performance@postgresql.org" Subject: Re: Pg makes nonoptimal choice between two multicolumn indexes with the same columns but in different order. References: <1388264608.60549.YahooMailNeo@web122306.mail.ne1.yahoo.com> In-Reply-To: <1388264608.60549.YahooMailNeo@web122306.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) 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 On 29/12/13 10:03, Kevin Grittner wrote: > Michael Kolomeitsev wrote: > >> it is clear for me why t1_b_a_idx is better. The question is: Is >> postgresql able to see that? > For a number of reasons I never consider a bulk load complete until > I run VACUUM FREEZE ANALYZE on the table(s) involved. When I try > your test case without that, I get the bad index choice. When I > then run VACUUM FREEZE ANALYZE on the database I get the good index > choice. > > There may be some lesser maintenance which sets up visibility > information and provides the planner with enough data to make a > good choice, I just noticed that you were not following what I > consider to be rote good practice, tried it, and it solved the > problem. > > -- > Kevin Grittner > EDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > Curious: Would it be feasible to do some kind of ANALYZE during a bulk operation? Say if you could tell the system you expected to change 20% of the records in advance: then you could sample some of the changes and modify the statistics with 0.2 times that plus 0.8 of the pre-existing statistics. BEGIN BULK OPERATION CHANGE 20% [... several transactions ...] END BULK OPERATION The sampling could be done as part of the individual operations or at the end of the bulk operation - whichever is deemed more practicable (possibly a bit of both?). Cheers, Gavin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance