To: "Abhijit Menon-Sen" <ams@oryx.com>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: switchover between index and sequential scans
In-Reply-To: <20080703075900.GA5735@toroid.org> (Abhijit Menon-Sen's message
	of "Thu\, 3 Jul 2008 13\:29\:00 +0530")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <20080703075900.GA5735@toroid.org>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Thu, 03 Jul 2008 11:05:46 +0100
Message-ID: <87hcb7b7ut.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Abhijit Menon-Sen" <ams@oryx.com> writes:

>          ->  Index Scan using header_fields_message_key on header_fields  (cost=0.00..1126.73 rows=325 width=4) (actual time=9.003..12.330 rows=17 loops=75)
>                Index Cond: (header_fields.message = "outer".message)
>
>          ->  Seq Scan on header_fields  (cost=0.00..85706.78 rows=1811778 width=4) (actual time=22.505..29281.553 rows=1812184 loops=1)

It looks to me like it's overestimating the number of rows in the index scan
by 20x and it's overestimating the cost of random accesses by about 100%.
Combined it's overestimating the cost of the index scan by about 40x.

> This machine has only 512MB of RAM, and is running FreeBSD 5.4. It has
> shared_buffers=3072, effective_cache_size=25000, work_mem=sort_mem=2048.
> Changing the last two doesn't seem to have any effect on the plan.

You could try dramatically increasing effective_cache_size to try to convince
it that most of the random accesses are cached. Or you could reach for the
bigger hammer and reduce random_page_cost by about half.

Also, if this box is dedicated you could make use of more than 24M for shared
buffers. Probably something in the region 64M-128M if your database is large
enough to warrant it.

And increase the statistics target on header_fields and re-analyze?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's RemoteDBA services!