Re: [WIP] Reduce alignment requirements on 64-bit systems. - Mailing list pgsql-hackers
From | Ryan Bradetich |
---|---|
Subject | Re: [WIP] Reduce alignment requirements on 64-bit systems. |
Date | |
Msg-id | e739902b0810091354k1d1405b0u67a436718cfb1d13@mail.gmail.com Whole thread Raw |
In response to | Re: [WIP] Reduce alignment requirements on 64-bit systems. (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
List | 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 by date: