Re: Determining scan types

From: "Richard Huxton" <dev(at)archonet(dot)com>
To: "Philip Molter" <philip(at)datafoundry(dot)net>, "Sam Tregar" <sam(at)tregar(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Determining scan types
Date: 2001-07-03 16:12:43
Message-ID: 005101c103dc$0b7b4140$1001a8c0@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

From: "Philip Molter" <philip(at)datafoundry(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alla 2001-07-03 16:29:35 Read-only mode
Previous Message Tom Lane 2001-07-03 15:58:56 Re: Please help recover data - lost pg_control