Re: Why is VACUUM ANALYZE <table> so slow?

From: David Shadovitz <david(at)shadovitz(dot)com>
To: 'Neil Conway' <neilc(at)samurai(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why is VACUUM ANALYZE <table> so slow?
Date: 2003-12-17 04:37:02
Message-ID: 01C3C415.9359D080.david@shadovitz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Neil,

Thanks for the good advice. I noticed that I had some sessions for which I
could not account, and I think even a 2nd postmaster running. It looks like
I've cleaned everything up, and now I can VACUUM and I can DROP an index which
wouldn't drop.

And I'm looking into upgrading PostgreSQL.

-David

On Tuesday, December 16, 2003 2:51 PM, Neil Conway [SMTP:neilc(at)samurai(dot)com]
wrote:
> "David Shadovitz" <david(at)www(dot)shadovitz(dot)com> writes:
> > I'm running PG 7.2.2 on RH Linux 8.0.
>
> Note that this version of PostgreSQL is quite old.
>
> > I'd like to know why "VACUUM ANALYZE <table>" is extemely slow (hours) for
> > certain tables.
>
> Is there another concurrent transaction that has modified the table
> but has not committed? VACUUM ANALYZE will need to block waiting for
> it. You might be able to get some insight into this by examining the
> pg_locks system view:
>
> http://www.postgresql.org/docs/current/static/monitoring-locks.html
>
> As well as the pg_stat_activity view.
>
> -Neil

Browse pgsql-performance by date

  From Date Subject
Next Message David Shadovitz 2003-12-17 04:42:58 Why is restored database faster?
Previous Message Christopher Kings-Lynne 2003-12-17 01:17:28 Re: Optimizing FK & PK performance...