Re: order of nested loop

"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
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.

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.

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.

regards, tom lane