From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Padding on 64-bit |
Date: | 2007-05-29 20:01:45 |
Message-ID: | 16938.1180468905@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2007-05-29 21:20:11 | Re: Padding on 64-bit |
Previous Message | Stephen Frost | 2007-05-29 19:57:29 | Re: Fixing insecure security definer functions |