RE: [HACKERS] Re: [PORTS] vacuum takes too long

From: "Jackson, DeJuan" <djackson(at)cpsgroup(dot)com>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, dave(at)turbocat(dot)de, ports(at)postgreSQL(dot)org, hackers(at)postgreSQL(dot)org
Subject: RE: [HACKERS] Re: [PORTS] vacuum takes too long
Date: 1999-01-07 17:31:56
Message-ID: F10BB1FAF801D111829B0060971D839F5BFABD@cpsmail
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-ports

> > With MVCC an occasional 'vacuum analyze' should only be
> noticed from the
> > performance improvements. As far as I can tell most of the
> work done by
> > an analyze is in reading the table data. If you make sure
> to write the
> > new information at the end of the transaction you only lock
> the indexes
> > for the amount of time it takes to write them.
> >
> > I see a 'vacuum analyze' being less of a problem than 'vacuum'.
> > Any of you experts can contradict my assumptions.
>
> Good point...I seem to recall that at one point, there was a
> lock imposed
> on one of hte pg_ tables when a vacuum is tarted, since it
> has to update a
> couple of the rows in that table...has that lock been removed
> with MVCC?
> Vadim?

Well, even if a vacuum locks whatever 'pg_'table-row that holds the
indexing statistics for the table in question MVCC won't block the
optimizer's reads. As long as there are no more vacuum analyzes run
there shouldn't even be a waiting transaction.
-DEJ

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-01-07 17:47:34 Re: [DOCS] Upcoming Attractions, web site
Previous Message Bruce Momjian 1999-01-07 17:31:06 Re: [DOCS] Upcoming Attractions, web site

Browse pgsql-ports by date

  From Date Subject
Next Message Bruce Momjian 1999-01-07 17:49:57 Re: [HACKERS] Re: [PORTS] vacuum takes too long
Previous Message The Hermit Hacker 1999-01-07 17:12:23 RE: [HACKERS] Re: [PORTS] vacuum takes too long