Greg Stark escribió: > On Fri, Dec 4, 2009 at 1:35 PM, Greg Stark <gsst...@mit.edu> wrote: > > If we lose vacuum full then the table's open for reducing the width of > > command id too if we need more bits. If we do that and we moved > > everything we could to the line pointers including ctid we might just > > be able to squeeze the tuple overhead down to 16 bytes. > > I'm not sure why I said "including ctid". We would have to move > everything transactional to the line pointer, including xmin, xmax, > ctid, all the hint bits, the updated flags, hot flags, etc. The only > things left in the tuple header would be things that have to be there > such as HAS_OIDS, HAS_NULLS, natts, hoff, etc. It would be a pretty > drastic change, though a fairly logical one.
Do we need XMAX_EXCL_LOCK and XMAX_SHARED_LOCK to be moved? It seems to me that they can stay with the tuple header because they are set by wal-logged operations. Same for XMAX_IS_MULTI. The HASfoo bits are all set on tuple creation, never touched later, so they can stay in the header too. We only need XMIN_COMMITTED, XMIN_INVALID, XMAX_COMMITTED, XMAX_INVALID, HEAP_COMBOCID on the line pointer AFAICS ... oh, and HEAP_HOT_UPDATED and HEAP_ONLY_TUPLE, not sure. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
