Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)
Дата
Msg-id 20001016094017.A272@fw.wintelcom.net
обсуждение исходный текст
Ответ на Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список pgsql-hackers
* Mikheev, Vadim <vmikheev@SECTORBASE.COM> [001016 09:33] wrote:
> >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.
> 
> >of undoing a WAL item, you mark the tuple invalid but don't physically
> >remove it till VACUUM (thus no need to worry about its index entries).
> 
> One of the purposes of WAL is immediate removing tuples 
> inserted by aborted xactions. I want make VACUUM
> *optional* in future - space must be available for
> reusing without VACUUM. And this is first, very small,
> step in this direction.

Why would vacuum become optional?  Would WAL offer an option to
not reclaim free space?  We're hoping that vacuum becomes unneeded
when postgresql is run with some flag indicating that we're
uninterested in time travel.

How much longer do you estimate until you can make it work that way?

thanks,
-Alfred


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: Ответ: [HACKERS] New file naming
Следующее
От: Alfred Perlstein
Дата:
Сообщение: Re: INHERITS doesn't offer enough functionality