Re: Remove xmin and cmin from frozen tuples
От | Tom Lane |
---|---|
Тема | Re: Remove xmin and cmin from frozen tuples |
Дата | |
Msg-id | 7861.1125542864@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Remove xmin and cmin from frozen tuples (ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>) |
Ответы |
Re: Remove xmin and cmin from frozen tuples
Re: Remove xmin and cmin from frozen tuples |
Список | pgsql-hackers |
ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp> writes: > I think it would be a waste to retain xmin and cmin for frozen tuples > because their values represent only 'visible for all transactions'. True, but the hard part is getting rid of the storage for them. > I wrote a makeshift patch to compress xmin and cmin (8bytes) to > 1-bit flag, using tuple overlaping. > Is this idea worth trying? I think this is incredibly ugly :-(. It eliminates a fairly basic assumption which is that items on a page don't overlap. The space savings cannot be worth the loss in testability and reliability. To take just one problem, it is no longer possible to check an item offset for validity against pd_upper. If we're going to do this, we need a more invasive patch that changes the structure of heaptuple headers in a more fundamental way, and avoids breaking the page layout representation. (Something like the way Oids are now handled might work, although there are alignment issues to worry about, and it'd take more work on VACUUM's part to convert a tuple to frozen state.) I'm also less than enthused about using up our last infomask bit for a relatively unimportant purpose. We might need that for something bigger someday... though I can't presently guess what. regards, tom lane
В списке pgsql-hackers по дате отправления: