Re: Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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