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
