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 по дате отправления: