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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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(at)momjian(dot)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
>

Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +