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
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... |