Re: Question regarding the database page layout.

Поиск
Список
Период
Сортировка
От Ryan Bradetich
Тема Re: Question regarding the database page layout.
Дата
Msg-id e739902b0809020149p38548baag8cb301d65b23f3d1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Question regarding the database page layout.  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Question regarding the database page layout.
Re: Question regarding the database page layout.
Re: Question regarding the database page layout.
Список pgsql-hackers
Hello all,

On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark <stark@enterprisedb.com> wrote:
>
> "Ryan Bradetich" <rbradetich@gmail.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: New FSM allocation policy
Следующее
От: "Ryan Bradetich"
Дата:
Сообщение: Re: statement_cost_limit for regression testing.