Thread: Padding on 64-bit
Hi! When running on a 64-bit server, are 32-bit ints padded to 64-bit? Specifically, I'm interested if I actually end up making my table any smaller if I move from 64-bit integer primary key to 32-bit. (Need to keep the index as small as possible to fit in cache) 64-bit on Debian linux running on Intel CPUs, if that make a difference. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> Specifically, I'm interested if I actually end up making my table any
> smaller if I move from 64-bit integer primary key to 32-bit.
Depends what else is in the row ... the overall row will get padded to
MAXALIGN, but if you were wasting 4 bytes on alignment before, then you
win.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Specifically, I'm interested if I actually end up making my table any >> smaller if I move from 64-bit integer primary key to 32-bit. > > Depends what else is in the row ... the overall row will get padded to > MAXALIGN, but if you were wasting 4 bytes on alignment before, then you > win. Ah, I see. Followup: Does it make a measurable performance difference for things like join or filtering operations, in case the storage size ends up being the same? //Magnus
Magnus Hagander <magnus@hagander.net> writes:
>>> Specifically, I'm interested if I actually end up making my table any
>>> smaller if I move from 64-bit integer primary key to 32-bit.
>>
>> Depends what else is in the row ... the overall row will get padded to
>> MAXALIGN, but if you were wasting 4 bytes on alignment before, then you
>> win.
> Ah, I see. Followup: Does it make a measurable performance difference
> for things like join or filtering operations, in case the storage size
> ends up being the same?
Hard to say. int8 is pass-by-reference, which is certainly slower than
pass-by-value, but you'd have to measure to see if it makes any
noticeable difference in your queries.
(I imagine someday we'll get around to allowing int8 to be pass-by-value
on 64-bit platforms.)
regards, tom lane
On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote: > (I imagine someday we'll get around to allowing int8 to be pass-by-value > on 64-bit platforms.) This could really be a significant performance win: I'm planning to take a look at doing it for 8.4. -Neil
Added to TODO: * Consider allowing 64-bit integers to be passed by reference on 64-bit platforms --------------------------------------------------------------------------- Neil Conway wrote: > On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote: > > (I imagine someday we'll get around to allowing int8 to be pass-by-value > > on 64-bit platforms.) > > This could really be a significant performance win: I'm planning to take > a look at doing it for 8.4. > > -Neil > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I think that's backwards. We *are* passing them by reference, we should be considering passing them by value. //Magnus Bruce Momjian wrote: > Added to TODO: > > * Consider allowing 64-bit integers to be passed by reference on 64-bit > platforms > > > --------------------------------------------------------------------------- > > Neil Conway wrote: >> On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote: >>> (I imagine someday we'll get around to allowing int8 to be pass-by-value >>> on 64-bit platforms.) >> This could really be a significant performance win: I'm planning to take >> a look at doing it for 8.4. >> >> -Neil >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 9: In versions below 8.0, the planner will ignore your desire to >> choose an index scan if your joining column's datatypes do not >> match >
Magnus Hagander wrote: > I think that's backwards. We *are* passing them by reference, we should > be considering passing them by value. Thanks, fixed. --------------------------------------------------------------------------- > > //Magnus > > > Bruce Momjian wrote: > > Added to TODO: > > > > * Consider allowing 64-bit integers to be passed by reference on 64-bit > > platforms > > > > > > --------------------------------------------------------------------------- > > > > Neil Conway wrote: > >> On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote: > >>> (I imagine someday we'll get around to allowing int8 to be pass-by-value > >>> on 64-bit platforms.) > >> This could really be a significant performance win: I'm planning to take > >> a look at doing it for 8.4. > >> > >> -Neil > >> > >> > >> > >> ---------------------------(end of broadcast)--------------------------- > >> TIP 9: In versions below 8.0, the planner will ignore your desire to > >> choose an index scan if your joining column's datatypes do not > >> match > > -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Magnus Hagander wrote:
>> I think that's backwards. We *are* passing them by reference, we should
>> be considering passing them by value.
> Thanks, fixed.
Also, the TODO item ought to mention float4 and float8, which IMHO ought
to be changed at the same time. float4 could become pass-by-val-always.
I think the main reason we've avoided that is to avoid breaking old code
that is not using DatumGet/GetDatum macros, but we'll be breaking most
such code anyway with this set of changes.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Magnus Hagander wrote: > >> I think that's backwards. We *are* passing them by reference, we should > >> be considering passing them by value. > > > Thanks, fixed. > > Also, the TODO item ought to mention float4 and float8, which IMHO ought > to be changed at the same time. float4 could become pass-by-val-always. > I think the main reason we've avoided that is to avoid breaking old code > that is not using DatumGet/GetDatum macros, but we'll be breaking most > such code anyway with this set of changes. Update: * Consider allowing 64-bit integers and floats to be passed by value on 64-bit platforms Also change 32-bit floats (float4) to be passed by value at the same time. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +