Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo) - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)
Date
Msg-id 20001016094017.A272@fw.wintelcom.net
Whole thread Raw
In response to Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List 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 by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: Ответ: [HACKERS] New file naming
Next
From: Alfred Perlstein
Date:
Subject: Re: INHERITS doesn't offer enough functionality