"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> I don't understand why WAL needs to log internal operations of any of
>> the index types. Seems to me that you could treat indexes as black
>> boxes that are updated as side effects of WAL log items for heap tuples:
>> when adding a heap tuple as a result of a WAL item, you just call the
>> usual index insert routines, and when deleting a heap tuple as a result
> On recovery backend *can't* use any usual routines:
> system catalogs are not available.
OK, good point, but that just means you can't use the catalogs to
discover what indexes exist for a given table. You could still create
log entries that look like "insert indextuple X into index Y" without
any further detail.
>> the index is corrupt and rebuild it from scratch, using Hiroshi's
>> index-rebuild code.
> How fast is rebuilding of index for table with 10^7 records?
It's not fast, of course. But the point is that you should seldom
have to do it.
> I agree to consider rtree/hash/gist as experimental
> index access methods BUT we have to have at least
> *one* reliable index AM with short down time/
> fast recovery.
With all due respect, I wonder just how "reliable" btree WAL undo/redo
will prove to be ... let alone the other index types. I worry that
this approach is putting too much emphasis on making it fast, and not
enough on making it right.
regards, tom lane
