On Sat, 2 Mar 2002, Tom Lane wrote:
Catching up with the lists.
> However, in Francisco's case he wants to completely replace the
> table contents
Not only that is correct, but now that we are "near" production I am
pushing even more data.
--- and if he wants to maintain service to clients
> while he does it, then there's no way around the fact that the
> peak space consumption is going to be twice the nominal table size.
Space is not a problem in my case.
> ones.) So if he just does VACUUMs then he's going to have a
> steady-state space consumption 2x larger than minimum, not a few
> percent larger than minimum. That might be annoying --- particularly
> if he's got queries that do sequential scans of the table. Might be
> worth a VACUUM FULL to knock the space usage back down.
Do sequential scans go over the entire space, including the space not in
use? It would be great if there was some kind of optimization that could
move the empty space towards the end. It would probably be an expensive
operation, but it may be very helpfull on databases with a big turnaround.
> (On the other hand, if the goal is "continuous service" then I
> think VACUUM FULL is out of the question anyway; it'll lock down
> the table for too long.)
I am doing VACUUM FULL weekly, but I am thinking whether to try daily. I
am only a bit concerned about how long it is going to take.
Does vacuum full locks only a table or the entire DB?
Specially if I did VACUUM FULL <table>.
I am thinking maybe scatter the VACUUM FULLs accross the week and doing
one table daily instead of trying the whole DB.
