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

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)
Date: 2000-10-16 16:40:17
Message-ID: 20001016094017.A272@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2000-10-16 16:42:23 Re: INHERITS doesn't offer enough functionality
Previous Message Mitch Vincent 2000-10-16 16:37:58 Full text indexing (Question/request)