Simon Riggs wrote:
On Mon, 2007-03-05 at 21:39 +0530, Pavan Deolasee wrote:
Currently each tuple is moved individually. You'd need to inspect the
whole HOT chain on a page, calculate space for that and then try to move
them all in one go. I was originally thinking that would be a problem,
but its not so bad - but it may cause us to end repair_frag() earlier
than we otherwise would depending upon the game of Tetris plays out.
Umm.. I still need to look deeper to understand the VACUUM FULL code,
but ISTM
that we can move tuple chains just the way its done today, without
bothering to keep
HOT-update chains intact. The tuples may actually got into different
pages and have
equal number of index entries. To my mind, this is not such a big
problem because
we shouldn't expect too many HOT-update chains while running VACUUM FULL.
Isn't that true ?
Thats harder than it sounds. My concern is that VACUUM FULL code is
fairly ugly and doing this might introduce a bug into a rarely used
piece of code that we don't pick up. I would not choose that path
myself, but we can go there if the consensus is that doing a reindex
would be the wrong way to go. Reindex will be fast to code and much more
likely to be bug-free.
Oh I agree. VACUUM FULL code is hard to assimilate. I am hoping that we can
make HOT work fine with VACUUM FULL without too many changes. If thats
not the case, I won't push for it.
You mean all moves will be cold?
So VACUUM FULL will actually bloat the indexes? I hope I've
misunderstood you.
Yes, thats what I meant. But are we really worried about bloating
indexes while
VACUUM FULL ? Any other tuple movements would anyway cause index
inserts. And I don't really expect too many tuple chains since VACUUM FULL
runs with AccessExclusive lock on the table.
Thanks,
Pavan
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
