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

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

On Thu, Oct 9, 2008 at 12:38 AM, Zdenek Kotala <Zdenek.Kotala@sun.com> wrote:
> Ryan Bradetich napsal(a):
>> On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala <Zdenek.Kotala@sun.com>
>> wrote:

>> 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.

Heh, understood. :)

I believe the proposed CRC patch also affects the heap page layout (adds
the pd_checksum field to the PageHeaderData). [1]   Just pointing out another
patch that could affect you as well.   My offer to help still stands.

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

Funny you should mention this.  I had just started looking into this
optimization
to see if I could convince myself it would be safe.  My initial
conclusion indicates
it would be safe, but I have not tested nor verified that yet.  Having
an independent
proposal for this boosts my confidence even more.   Thanks!

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

Just to clarify, this patch only affects heap storage when (i.e. the
is_heap flag is
set).   I have not had a chance to analyze or see if I can reduce
other storage types
yet.

> 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.

Thanks.  I will do.

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

Great.  That is some of the feedback I was looking for.  I did not
implement it yet,
because I wanted to see if the basic implementation was feasible first.

Thanks again for your feedback!

- Ryan


[1] http://archives.postgresql.org/pgsql-hackers/2008-10/msg00070.php


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: CREATE DATABASE vs delayed table unlink
Следующее
От: Tom Lane
Дата:
Сообщение: Re: bytea to XML crash fix