Message-ID: <4F7D8B3F.1030402@ulb.ac.be>
Date: Thu, 05 Apr 2012 14:08:31 +0200
From: Julien Cigar <jcigar@ulb.ac.be>
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: Re: bad plan
References: <4F7D843E.4060304@ulb.ac.be> <4F7D89F5.7090301@gmail.com>
In-Reply-To: <4F7D89F5.7090301@gmail.com>
Content-Type: multipart/mixed; boundary="------------030006090400080108060302"

This is a multi-part message in MIME format.
--------------030006090400080108060302
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Mario,

The query is in the pastie.org links, here is a copy:

SELECT
   t_geo.frequence, ST_SetSRID(gc.geom, 4326) as geom
FROM (
   SELECT
     geo_id , count(*) AS frequence
   FROM
hit.context_to_context_links
   WHERE
     NOT geo_id IS NULL ANDtaxon_id= ANY (
       SELECT
         taxon_id
       FROM
         rab.ancestors
       WHERE
         ancestors.subphylum_id = 18830
       ) GROUP BY geo_id
) as t_geo
JOIN
   hit.geo_candidates gc ON gc.id = t_geo.geo_id;

Thank you,
Julien

On 04/05/2012 14:03, Mario Dankoor wrote:
> Julien,
>
> It looks like you forgot to post the query.
>
> Mario
> On 2012-04-05 1:38 PM, Julien Cigar wrote:
>> 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.


--------------030006090400080108060302
Content-Type: text/x-vcard; charset=utf-8;
 name="jcigar.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="jcigar.vcf"

YmVnaW46dmNhcmQNCmZuOkp1bGllbiBDaWdhcg0KbjpDaWdhcjtKdWxpZW4NCm9yZztxdW90
ZWQtcHJpbnRhYmxlOkJlbGdpYW4gQmlvZGl2ZXJzaXR5IFBsYXRmb3JtO1VMQiAoVW5pdmVy
c2l0PUMzPUE5IExpYnJlIGRlIEJydXhlbGxlcykNCmFkcjo7OztCcnVzc2Vsczs7O0JlbGdp
dW0NCmVtYWlsO2ludGVybmV0OmpjaWdhckB1bGIuYWMuYmUNCnRlbDt3b3JrOiszMigwKTI2
NTA1NzUyDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0KdXJsOmh0dHA6Ly93d3cuYmlvZGl2ZXJz
aXR5LmJlDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg==
--------------030006090400080108060302--