Re: Determining scan types - Mailing list pgsql-general

From Richard Huxton
Subject Re: Determining scan types
Date
Msg-id 005101c103dc$0b7b4140$1001a8c0@archonet.com
Whole thread Raw
In response to Determining scan types  (Philip Molter <philip@datafoundry.net>)
Responses Re: Determining scan types  (Philip Molter <philip@datafoundry.net>)
List pgsql-general
From: "Philip Molter" <philip@datafoundry.net>

> On Tue, Jul 03, 2001 at 10:42:37AM -0400, Sam Tregar wrote:
> : On Tue, 3 Jul 2001, Philip Molter wrote:
> :
> : > What causes this and how can I fix it?
> :
> : Have you tried a VACUUM ANALYZE?  For some reason Postgres isn't able to
> : use its indexes fully unless you VACUUM ANALYZE often.
> :
> : I consider this a bug but I gather the developers are OK with it.
>
> Yes.  In fact, I have to VACUUM ANALYZE the tables every half hour on
> this constantly running system or else kernel CPU usage rises to
> unacceptable levels (another thing I consider a bug).  Like I said, in
> the middle of the night (probably after one of these analyses), it
> switched from using index scans where appropriate to using sequential
> scans for everything.  If I turn off sequential scans altogether, it
> uses the indices, but I don't get the performance of benefits of using
> sequential scans when appropriate.

VACUUM ANALYZE frequency depends on numbers of updates. I believe someone
has been looking at a way of doing this in the background.

For the purposes of setting SEQSCAN try something like:

SET ENABLE_SEQSCAN TO OFF;

Can't remember if it applies to this transaction or this connection. Run a
grep on the docs - you'll only find a couple of hits.

HTH

- Richard Huxton


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Please help recover data - lost pg_control
Next
From: Philip Molter
Date:
Subject: Re: Determining scan types