Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 9743C1BA1319 for ; Thu, 5 Apr 2012 08:38:54 -0300 (ADT) Received: from mxin.ulb.ac.be ([164.15.128.112]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SFl1g-0001Jg-JS for pgsql-sql@postgresql.org; Thu, 05 Apr 2012 11:38:53 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAL2DfU+kD30E/2dsb2JhbAANNoV8tjdVPRYLAgsDAgECAS8QGQgBAQUStG2LCY02ggyBGASOa4EjizqFXYdj Received: from bebif01.ulb.ac.be (HELO [10.0.0.194]) ([164.15.125.4]) by smtp.ulb.ac.be with ESMTP; 05 Apr 2012 13:38:38 +0200 Message-ID: <4F7D843E.4060304@ulb.ac.be> Date: Thu, 05 Apr 2012 13:38:38 +0200 From: Julien Cigar Organization: Belgian Biodiversity Platform User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120314 Thunderbird/10.0.2 MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: bad plan Content-Type: multipart/mixed; boundary="------------080200090503010405020601" X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201204/9 X-Sequence-Number: 36486 This is a multi-part message in MIME format. --------------080200090503010405020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have an extremely bad plan for one of my colleague's query. Basically PostgreSQL chooses to seq scan instead of index scan. This is on: antabif=# select version(); version ---------------------------------------------------------------------------------------------------------- PostgreSQL 9.0.7 on amd64-portbld-freebsd8.2, compiled by GCC cc (GCC) 4.2.1 20070719 [FreeBSD], 64-bit The machines has 4GB of RAM with the following config: - shared_buffers: 512MB - effective_cache_size: 2GB - work_mem: 32MB - maintenance_work_mem: 128MB - default_statistics_target: 300 - temp_buffers: 64MB - wal_buffers: 8MB - checkpoint_segments = 15 The tables have been ANALYZE'd. I've put the EXPLAIN ANALYZE on: - http://www.pastie.org/3731956 : with default config - http://www.pastie.org/3731960 : this is with enable_seq_scan = off - http://www.pastie.org/3731962 : I tried to play on the various cost settings but it's doesn't change anything, except setting random_page_cost to 1 (which will lead to bad plans for other queries, so not a solution) - http://www.pastie.org/3732035 : with enable_hashagg and enable_hashjoin to false I'm currently out of idea why PostgreSQL still chooses a bad plan for this query ... any hint :) ? Thank you, Julien -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --------------080200090503010405020601 Content-Type: text/x-vcard; charset=utf-8; name="jcigar.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jcigar.vcf" begin:vcard fn:Julien Cigar n:Cigar;Julien org;quoted-printable:Belgian Biodiversity Platform;ULB (Universit=C3=A9 Libre de Bruxelles) adr:;;;Brussels;;;Belgium email;internet:jcigar@ulb.ac.be tel;work:+32(0)26505752 x-mozilla-html:FALSE url:http://www.biodiversity.be version:2.1 end:vcard --------------080200090503010405020601--