Re: AW: update on TOAST status'

JanWieck@t-online.de (Jan Wieck) writes:
>     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?

I don't see a "specialized" way that would be any different in
performance from a "generalized" solution.  The hard part AFAICT is how
does a newly-started backend discover the current version numbers for
the critical system tables and indexes.  To do versioning of system
indexes at all, we need a full-fledged solution.

But as you pointed out before, none of the system indexes are on
toastable datatypes.  (I just checked --- the only index opclasses used
in template1 are: int2_ops int4_ops oid_ops char_ops oidvector_ops
name_ops.)  Maybe we could have an interim solution using the old method
for system indexes and a drop-and-rebuild approach for user indexes.
A crash partway through rebuild would leave you with a busted index,
but maybe WAL could take care of redoing the index build after restart.
(Of course, if the index build failure is reproducible, you're in
big trouble...)

I don't *like* that approach a whole lot; it's ugly and doesn't sound
all that reliable.  But if we don't want to deal with relation
versioning for 7.1, maybe it's the only way for now.

			regards, tom lane