| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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 12:48:43 |
| Message-ID: | 1259930923.13774.38288.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2009-12-04 at 07:12 -0500, Bruce Momjian wrote:
> I think the hint bit has to be added to the item pointer, by using the
> offset bits that are already zero, according to Greg Stark. That
> solution leads to easy programming, no expanding hint bit array, and it
> is backward compatible so doesn't cause problems for pg_migrator.
Seems like a reasonable way forward.
As I pointed out here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg00056.php
we only need to use 3 bits not 4, but it does limit tuple length to 4096
for all block sizes. (Two different options there for doing that).
An added advantage of this approach is that the cachelines for the item
pointer array will already be in CPU cache, so there is no additional
access time when we set the hint bits when they are moved to their new
position.
I should also point out that removing 4 bits from the tuple header would
allow us to get rid of t_infomask2, reducing tuple length by a further 2
bytes.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2009-12-04 12:52:00 | Re: Block-level CRC checks |
| Previous Message | Bruce Momjian | 2009-12-04 12:12:54 | Re: Block-level CRC checks |