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 |
Subject: | RE: Berkeley DB... |
Date: | 2000-05-22 03:00:01 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018BF7@SECTORBASE1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > And, while we are on heap subject - using index (RECNO) for heap
> > means that all our secondary-index scans will performe TWO
> > index scans - first, to find recno in secondary-index, and
> > second, to find heap tuple using recno (now indices give us
> > TID, which is physical address).
>
> 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 -:)
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2000-05-22 03:09:54 | RE: Berkeley DB... |
Previous Message | Lamar Owen | 2000-05-22 02:26:54 | Re: PostgreSQL 7.0-2 RPMset released. |