Re: order of nested loop
От | Jim C. Nasby |
---|---|
Тема | Re: order of nested loop |
Дата | |
Msg-id | 20030618183606.GS40542@flake.decibel.org обсуждение исходный текст |
Ответ на | Re: order of nested loop (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Wed, Jun 18, 2003 at 01:42:02AM -0400, Tom Lane wrote: > "Jim C. Nasby" <jim@nasby.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@nasby.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?"
В списке pgsql-general по дате отправления: