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

Поиск
Список
Период
Сортировка
От Ryan Bradetich
Тема Re: [WIP] Reduce alignment requirements on 64-bit systems.
Дата
Msg-id e739902b0810091354k1d1405b0u67a436718cfb1d13@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [WIP] Reduce alignment requirements on 64-bit systems.  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
Hello ITAGAKI-san,

I apologize for not replying earlier, I needed to head out to work.

On Thu, Oct 9, 2008 at 5:01 AM, ITAGAKI Takahiro
<itagaki.takahiro@oss.ntt.co.jp> wrote:
> "Ryan Bradetich" <rbradetich@gmail.com> wrote:
>> Here is a proof-of-concept patch for reducing the alignment
>> requirement for heap tuples on 64-bit systems.
>>
>> pg_depend         312 kB                  296 kB
>> pg_description    160 kB                  152 kB
>
> 5 percent of gain seems reasonable for me.

I agree.   I am seeing ~10% gain in some of my tables where
the tuple size was 44 bytes but due to the alignment was being
padded out to 48 bytes.

> Is it possible to apply your improvement for indexes?
> I think there are more benefits for small index entries
> that size are often 12 or 20 bytes.

I am not sure if this improvement will affect indexes or not yet.  My
current implementation specifically excludes indexes and only affects
heap tuples.   Now that I have a better understanding of the disk
structure for heap tuples, I am planning to look at the index layout in the
near future to see if there is some possible gain there as well.

>> This would completely eliminate the impact for this
>> patch on 32-bit systems, which would not gain any benefit from this patch.
> No! There are *also* benefits even on 32-bit systems, because some
> of them have 8-byte alignment. (for example, 32-bit Windows)

Excellent!  I was not aware of that.   Thanks for this information.

Any ideas on what I should use for this check?
I was thinking of using #if SIZEOF_SIZE_T = 8
Guess I should search around for standard solution for this problem.

> BTW, there might be a small mistabke on the following lines in patch.
> They do the same things ;-)
>
> ***************
> *** 1019,1025 **** toast_flatten_tuple_attribute(Datum value,
>                new_len += BITMAPLEN(numAttrs);
>        if (olddata->t_infomask & HEAP_HASOID)
>                new_len += sizeof(Oid);
> !       new_len = MAXALIGN(new_len);
>        Assert(new_len == olddata->t_hoff);
>        new_data_len = heap_compute_data_size(tupleDesc,
>                                                                                  toast_values, toast_isnull);
> --- 1025,1034 ----
>                new_len += BITMAPLEN(numAttrs);
>        if (olddata->t_infomask & HEAP_HASOID)
>                new_len += sizeof(Oid);
> !       if (olddata->t_infomask & HEAP_INTALIGN)
> !               new_len = MAXALIGN(new_len);
> !       else
> !               new_len = MAXALIGN(new_len);
>        Assert(new_len == olddata->t_hoff);
>        new_data_len = heap_compute_data_size(tupleDesc,
>                                                                                  toast_values, toast_isnull);

Thanks for that catch!  I have this fixed in my local GIT tree now.

Thanks for your feedback and review!

- Ryan


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

Предыдущее
От: Grzegorz Jaskiewicz
Дата:
Сообщение: Re: head's linking problem
Следующее
От: Ron Mayer
Дата:
Сообщение: Re: 8.3 vs HEAD difference in Interval output?