Padding on 64-bit

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. +

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. +

I think that's backwards. We *are* passing them by reference, we should
be considering passing them by value.

//Magnus

Bruce Momjian 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.

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. +