Re: AW: update on TOAST status'

I wrote:
>
> Maybe we could propagate key range changes into upper blocks
> at index_delete() time. Will look at the btree code now.

After looking at the vacuum code it doesn't seem to be a good
idea. Doing so would require to traverse the btree first,
while the current implementation just grabs the block by
index ctid and pulls out the tuple. I would expect it to
significantly slow down vacuum again - what we all don't
want.

So the only way left is recreating the indices from scratch
and moving the new ones into place.

But in contrast to things like column dropping, this would
have to happen on every vacuum run for alot of tables.

Isn't it appropriate to have a specialized version of it for
this case instead of waiting for a general relation
versioning?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #