From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: order of nested loop |
Date: | 2003-06-18 18:36:06 |
Message-ID: | 20030618183606.GS40542@flake.decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jun 18, 2003 at 01:42:02AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > ... I'm sure there's plenty of other ways MVCC info could be
> > stored without using 16/20 bytes per tuple.
>
> I didn't really see a single workable idea there. Keep in mind that
> storage space is only one consideration (and not a real big one given
> modern disk-drive sizes). Ask yourself about atomicity, failure
Disk space is cheap; disk bandwidth is insanely expensive, as is memory
bandwidth.
> recovery, and update costs. RLE encoding of tuple states? Get real ---
> how many rows could get wiped out by a one-bit lossage? How extensive
> are the on-disk changes needed to encode a one-tuple change in state,
> and how do you recover if the machine crashes when only some of those
> changes are down to disk? In my opinion PG's on-disk structures are
> barely reliable enough now; we don't want to introduce compression
> schemes with the potential for large cross-tuple failure modes.
Well, with more efficient MVCC info storage, adding error correction
capability becomes more practical. On the other hand, is it really
pgsql's responsibility to handle errors caused by bad hardware? I
don't think any other database tries to.
> Storing commit state in index entries has been repeatedly proposed
> and repeatedly rejected, too. It converts an atomic operation
> (update one word in one page) into a non-atomic, multi-page operation,
> which creates lots of performance and reliability problems. And the
> point of an index is to be smaller than the main table --- the more
> stuff you cram into an index tuple header, the less the advantage
> of having the index.
Well, it doesn't have to be stored in the index itself. Moving MVCC
information to a seperate set of pages from the base tuples would
provide the same ability.
> Criticism in the form of a patch with experimental evidence is welcome,
> but I'm not really interested in debating what-if proposals, especially
> not ones that are already discussed in the archives.
Fair enough, though I hope some others are interested since my C coding
ability is nil.
Can you point me at the archived discussions? Searching for index and
mvcc reveals nothing (actually, searching for 'index' returns nothing,
which surely must be a bug).
--
Jim C. Nasby (aka Decibel!) jim(at)nasby(dot)net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos | 2003-06-18 18:38:33 | Allowing user to connect to a database? |
Previous Message | Stephan Szabo | 2003-06-18 18:30:04 | Re: can't "grant all on database..." |