From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question on alignment |
Date: | 2019-04-01 13:40:03 |
Message-ID: | 6475.1554126003@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Antonin Houska <ah(at)cybertec(dot)at> writes:
> Antonin Houska <ah(at)cybertec(dot)at> wrote:
>> Since palloc() only ensures MAXIMUM_ALIGNOF, that wouldn't help here anyway.
> After some more search I'm not sure about that. The following comment
> indicates that MAXALIGN helps too:
Well, there is more than one thing going on here, and more than one
level of potential optimization. On just about any hardware I know,
misalignment below the machine's natural word width is going to cost
cycles in memcpy (or whatever equivalent the kernel is using). Intel
CPUs tend to throw many many transistors at minimizing such costs, but
that still doesn't make it zero. On some hardware, you can get further
speedups with alignment to a bigger-than-word-width boundary, allowing
memcpy to use specialized instructions (SSE2 stuff on Intel, IIRC).
But there's a point of diminishing returns there, plus it takes extra
work and more wasted space to arrange for anything to have extra
alignment. So we generally only bother with ALIGNOF_BUFFER for shared
buffers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-01 13:44:05 | Re: [HACKERS] generated columns |
Previous Message | Michael Paquier | 2019-04-01 13:37:31 | Re: Question on alignment |