Re: [WIP] Reduce alignment requirements on 64-bit systems.

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: [WIP] Reduce alignment requirements on 64-bit systems.
Дата
Msg-id 48EDB4EE.5070705@sun.com
обсуждение исходный текст
Ответ на Re: [WIP] Reduce alignment requirements on 64-bit systems.  ("Ryan Bradetich" <rbradetich@gmail.com>)
Ответы Re: [WIP] Reduce alignment requirements on 64-bit systems.  ("Ryan Bradetich" <rbradetich@gmail.com>)
Список pgsql-hackers
Ryan Bradetich napsal(a):
> Hello Zdenek,

Hello Ryan,

> 
> On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala <Zdenek.Kotala@sun.com> wrote:
>> Just a quick look. At first point. Your change introduces new page layout
>> version. Which is not acceptable from my point of view for 8.4 (it add
> 
> I would like to see this patch (or some variant) go in if possible.
> Since the inplace
> upgrades a concern to you, is there anything I can do to help with the inplace
> upgrades to help offset the disruption this patch causes you?

Yaah, wait until 8.5 :-). However, currently there is no clear consensus which 
upgrade method is best. I hope that It will clear after Prato developers 
meeting. Until this meeting I cannot say more.

>> another complexity to inplace upgrade). And I guest that it maybe works fine
>> on 64bits x86 but it will fail on SPARC and other machine which requires
>> aligned data.
> 
> Did I miss something?  My intention was to keep the data aligned so it
> should work
> on any platform.   The patch checks the user-defined data to see if
> any column requires
> the double storage type.  If the double storage type is required, it
> uses the MAXALIGN()
> macro which preserves the alignment for 64-bit data types.   If no
> columns require the
> double storage type, then the data will be INTALIGN() which still
> preserves the alignment
> requirements.  

I overlooked 'd' test. Your idea seems to me reasonable. Maybe, you could test 
'd' alignment only for NOT NULL values.

> If I have a complete mis-understanding of this issue,
> please explain it
> to me and I will either fix it or withdraw the patch.

The problem there is add_item which it is used for indexes as well and they has  IndexTupleHeader structure. I'm not
convenienceabout idea has two different 
 
alignment for items on page.

I guess another problem is with MAX_TUPLE_CHUNK_SIZE which uses MAXALIGN for 
computing. It seems to me that toast chunk could waste a space anyway.

And of course you should bump page layout version.

I also suggest create function/macro to compute hoff and replace code with this 
function/macro.
    Zdenek



-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



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

Предыдущее
От: "Ryan Bradetich"
Дата:
Сообщение: Re: [WIP] Reduce alignment requirements on 64-bit systems.
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: trigger functions broken?