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@Yahoo.com #
