Date: Mon, 22 May 2006 10:25:51 -0500
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Brendan Duddridge <brendan@clickspace.com>
Cc: Ragnar <gnari@hive.is>,
	PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Performs WAY better with enable_seqscan = off
Message-ID: <20060522152549.GO64371@pervasive.com>
References: <E9515F1E-AB80-483D-A15F-3BB347C721AB@clickspace.com>
	<1148208611.28240.101.camel@localhost.localdomain>
	<BA21CBE9-E89E-4DB6-BA04-FEED87E9B4A0@clickspace.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BA21CBE9-E89E-4DB6-BA04-FEED87E9B4A0@clickspace.com>
User-Agent: Mutt/1.5.11

On Sun, May 21, 2006 at 02:01:14PM -0600, Brendan Duddridge wrote:
> When the query planner uses the indexes with the concatenated values  
> and the where clause, the query can be sub-second response times (but  
> not always depending on the category_id value). By just doing a  
> regular join as you suggested, it's always slower. The trick is  
> getting Postgres to use the proper index all the time. And so far the  
> only way I can do that is by turning off sequential scans, but that's  
> something I didn't want to do because I don't know how it would  
> affect the performance of the rest of my application.
 
You can always disable them for just that query...
BEGIN;
SET LOCAL enable_seqscan=off;
SELECT ...
COMMIT;

> Just a note, I have random_page_cost set to 1 to try and get it to  
> favour index scans. The database machine has 8GB of RAM and I have  
> effective_cache_size set to 2/3 of that.

That's rather low for that much memory; I'd set it to 7GB.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461