From: | "Ryan Bradetich" <rbradetich(at)gmail(dot)com> |
---|---|
To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] Reduce alignment requirements on 64-bit systems. |
Date: | 2008-10-09 20:54:45 |
Message-ID: | e739902b0810091354k1d1405b0u67a436718cfb1d13@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> "Ryan Bradetich" <rbradetich(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2008-10-09 21:23:03 | Re: 8.3 vs HEAD difference in Interval output? |
Previous Message | Jaime Casanova | 2008-10-09 20:41:55 | avoid create a tablespace in pg_tblspc |