Re: Vacuum questions... - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Vacuum questions...
Date
Msg-id 20050926181325.GO30974@pervasive.com
Whole thread Raw
In response to Re: Vacuum questions...  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Sat, Sep 24, 2005 at 08:25:30PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> 
> >Would it be difficult to vacuum as part of a dump? The reasoning behind
> >this is that you have to read the table to do the dump anyway, so it
> >would be a good time to be able to piggy-back other operations that need
> >to read the entire table on top. I know vacuuming of indexes complicates
> >this, so it's probably not as simple as just firing off a vacuum and
> >copy at the same time (although that idea is probably worth testing,
> >since it might still be a win).
> > 
> >
> This would be a nightmare on a large database. Think of how
> long it takes to dump 20 gig, now add how long it is going to
> take to vacuum that size of DB, now think about a 500 gig
> database.

What says that the length of the dump is limited by the disks the
database is on? I suspect in many cases it's not.

Anyway, this would certainly be an optional step, so if it turns out it
hurts you in your environment, you don't have to use it.

> Actually this also probably would not gain you much in 8.1
> as vacuum in theory is already dealing with itself.

Maybe, maybe not. If you're already reading the entire table to dump it,
why read the entire table again some other time to vacuum it. Just get
it all done at once.

Whenever we get a 'map of pages that need vacuuming' which will
presumably greatly speed up vacuum then maybe your argument makes sense.
Right now I don't see how it helps anything.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Open items list for 8.1
Next
From: "Jim C. Nasby"
Date:
Subject: Re: \d on database with a lot of tables is slow