Greg Stark escribió:
> On Fri, Dec 4, 2009 at 1:35 PM, Greg Stark <gsstark@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
