Re: bad plan

From: Mario Dankoor <m(dot)p(dot)dankoor(at)gmail(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: bad plan
Date: 2012-04-05 12:03:01
Message-ID: 4F7D89F5.7090301@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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
>
>
>

In response to

  • bad plan at 2012-04-05 11:38:38 from Julien Cigar

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Julien Cigar 2012-04-05 12:08:31 Re: bad plan
Previous Message Julien Cigar 2012-04-05 11:38:38 bad plan