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
