From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "'Michael A(dot) Olson'" <mao(at)sleepycat(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Berkeley DB... |
Date: | 2000-05-22 03:09:54 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018BF8@SECTORBASE1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Yes, that was one of my questions. Why use recno at all?
> > We already have heap access which is very fast. Why switch
> > to SDB which gives us a recno ordering of heap that doesn't
> > do us any real good, except to allow tuple update without
> > changing indexes.
>
> But if we'll use our heap AM, then we'll have to implement redo/undo
> for it... no sence to switch to SDB for btree/hash WAL support -:)
Also, I think that our native index logging will require less space
in log, because of we can do not write *key values* to log!
Index tuple insertion will be logged as "index tuple pointing to
heap TID was added to page BLKNO at position ITEMID".
The same for index page split...
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-22 03:11:00 | Re: Berkeley DB... |
Previous Message | Mikheev, Vadim | 2000-05-22 03:00:01 | RE: Berkeley DB... |