Skip site navigation (1) Skip section navigation (2)

bad plan

From: Julien Cigar <jcigar(at)ulb(dot)ac(dot)be>
To: pgsql-sql(at)postgresql(dot)org
Subject: bad plan
Date: 2012-04-05 11:38:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql

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();
  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:

- : with default config
- : this is with enable_seq_scan = off
- : 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)
- : 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,

No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.

Attachment: jcigar.vcf
Description: text/x-vcard (292 bytes)


pgsql-sql by date

Next:From: Mario DankoorDate: 2012-04-05 12:03:01
Subject: Re: bad plan
Previous:From: Pavel StehuleDate: 2012-04-04 07:36:19
Subject: Re: how to write cursors

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group