Re: Block-level CRC checks

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, decibel <decibel(at)decibel(dot)org>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, jd(at)commandprompt(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2009-12-04 13:44:20
Message-ID: 407d949e0912040544r29874e98n9029e5ed3d70d6a1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 4, 2009 at 1:35 PM, Greg Stark <gsstark(at)mit(dot)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. I recall someone actually
submitted a patch to separate out the transactional bits anyways a
while back, just to save a few bytes in in-memory tuples. If we could
save on disk-space usage it would be a lot more compelling. But it
doesn't look to me like it really saves enough often enough to be
worth so much code churn.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2009-12-04 13:46:38 Re: [CORE] EOL for 7.4?
Previous Message Greg Stark 2009-12-04 13:35:07 Re: Block-level CRC checks