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
