Re: Question regarding the database page layout.

From: "Ryan Bradetich" <rbradetich(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question regarding the database page layout.
Date: 2008-09-02 08:49:43
Message-ID: e739902b0809020149p38548baag8cb301d65b23f3d1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello all,

On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
>
> > After a cursory glance at the HeapTupleHeaderData structure, it appears it
> > could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
> > worried about was the 6 byte t_ctid structure. The comments in
> > src/include/storage/itemptr.h file indicate the ItemPointerData structure is
> > composed of 3 int16 fields. So everthing in the HeapTupleHeaderData
> > structure is 32-bits or less.
>
> Sure, but the tuple itself could contain something with double alignment. If
> you have a bigint or double in the tuple then heap_form_tuple needs to know
> where to put it so it ends up at right alignment.

For fun, I looked around in heap_form_tuple() today to see how big of a job this
change would be. It did not seem very hard to implement. I know there are
probably several other places I missed with this patch, but this patch does pass
the regression tests and simple testing I threw at it (including ALTER TABLE
ADD COLUMN, etc).

The patch concept is fairly simple.

1. Add a new boolean local variable: require_max_align
(initialized to false).
2. When we loop through the attributes, check to see if any
attributes require
double alignment. If they do, set require_max_align = true.
3. If the tuple has OIDS (double alignment requirement), set
require_max_align = true.
4. If require_max_align = true, use the MAXALIGN macro; otherwise
use the INTALIGN macro.

A check of the physical storage for my previous test case does show
the tuple length to be 44 bytes
instead of the previous 48 bytes, so the patch does appear to work. I
have not run any performance
tests using this patch, etc.

Attached is my proof-of-concept patch for this idea in case someone
wants to inform me of other
problems this patch will introduce :)

Thanks,

- Ryan

Attachment Content-Type Size
reduce-heaptuple-size-poc.patch text/x-diff 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Bradetich 2008-09-02 08:52:06 Re: statement_cost_limit for regression testing.
Previous Message Simon Riggs 2008-09-02 08:44:24 Re: rmgr hooks and contrib/rmgr_hook