| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, 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>, 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 15:48:27 |
| Message-ID: | 25163.1259941707@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> 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.
It would also break things for indexes, which don't need all that stuff
in their line pointers.
More to the point, moving the same bits to someplace else on the page
doesn't save anything at all.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-12-04 15:50:36 | Upcoming update releases |
| Previous Message | Tom Lane | 2009-12-04 15:43:55 | Re: Block-level CRC checks |