Re: Performs WAY better with enable_seqscan = off

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Brendan Duddridge <brendan(at)clickspace(dot)com>
Cc: Ragnar <gnari(at)hive(dot)is>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performs WAY better with enable_seqscan = off
Date: 2006-05-22 15:25:51
Message-ID: 20060522152549.GO64371@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-22 15:30:08 Re: Performs WAY better with enable_seqscan = off
Previous Message Jim C. Nasby 2006-05-22 15:21:18 Re: utilizing multiple disks for i/o performance