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