Re: Slow Delete : Seq scan instead of index scan

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Filippos Kalamidas <filippos(dot)kal(at)gmail(dot)com>
Cc: Sylvain CAILLET <scaillet(at)alaloop(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow Delete : Seq scan instead of index scan
Date: 2012-10-17 06:19:49
Message-ID: 507E4E05.9040400@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 10/16/2012 04:41 PM, Filippos Kalamidas wrote:
> the first thing you should probably do is run an 'analyze' on one of
> these tables and then run again the delete statement. if there are no
> stats for these tables, it's normal not to have very good plans.

Yep, and the fact that the stats are that bad suggests that autovaccum
probably isn't running, or isn't running often enough.

If you have a high INSERT/UPDATE/DELETE load, then turn autovacuum up on
that table. See:

http://www.postgresql.org/docs/current/static/routine-vacuuming.html


http://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

If the table is badly bloated it might be worth running "VACUUM FULL" on
it or (if you're on PostgreSQL 8.4 or below) instead CLUSTER the table
on an index, as "VACUUM FULL" is very inefficient in 8.4 and older (I
think; I might be misremembering the versions).

Please specify your PostgreSQL version in all questions. See
https://wiki.postgresql.org/wiki/Slow_Query_Questions

--
Craig Ringer

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Yetkin Öztürk 2012-10-17 07:05:05 pgbounce max_client_conn and default_pool_size
Previous Message Florent Guillaume 2012-10-17 04:38:01 Re: WebSphere Application Server support for postgres