Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-ports by date

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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group