On Thu, Sep 11, 2014 at 02:54:36PM -0300, Arthur Silva wrote:
> Indeed I don't know any other architectures that this would be at an
> option. So if this ever moves forward it must be turned on at compile time
> for x86-64 only. I wonder how the Mysql handle their rows even on those
> architectures
On Thu, Sep 11, 2014 at 12:39 PM, Tom Lane wrote:
> Merlin Moncure writes:
> > Be advised of the difficulties you are going to face here. Assuming
> > for a second there is no reason not to go unaligned on Intel and there
> > are material benefits to justify the effort, that doesn't necessarily
On Thu, Sep 11, 2014 at 11:27 AM, Andres Freund
wrote:
> On 2014-09-11 10:32:24 -0300, Arthur Silva wrote:
> > Unaligned memory access received a lot attention in Intel post-Nehalen
> era.
> > So it may very well pay off on Intel servers. You might find this blog
> post
> > and it's comments/exte
On 2014-09-11 11:39:12 -0400, Tom Lane wrote:
> Even on Intel, I'd wonder what unaligned accesses do to atomicity
> guarantees and suchlike.
They pretty much kill atomicity guarantees. Atomicity is guaranteed
while you're inside a cacheline, but not once you span them.
> This is not a big deal fo
Merlin Moncure writes:
> Be advised of the difficulties you are going to face here. Assuming
> for a second there is no reason not to go unaligned on Intel and there
> are material benefits to justify the effort, that doesn't necessarily
> hold for other platforms like arm/power.
Note that on ma
On Thu, Sep 11, 2014 at 8:32 AM, Arthur Silva wrote:
>
> On Wed, Sep 10, 2014 at 12:43 PM, Robert Haas wrote:
>>
>> On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva wrote:
>> > I'm continuously studying Postgres codebase. Hopefully I'll be able to
>> > make
>> > some contributions in the future.
>>
On 2014-09-11 10:32:24 -0300, Arthur Silva wrote:
> Unaligned memory access received a lot attention in Intel post-Nehalen era.
> So it may very well pay off on Intel servers. You might find this blog post
> and it's comments/external-links interesting
> http://lemire.me/blog/archives/2012/05/31/da
On Thu, Sep 11, 2014 at 9:32 AM, Arthur Silva wrote:
> I thought all memory alignment was (or at least the bulk of it) handled
> using some codebase wide macros/settings, otherwise how could different
> parts of the code inter-op? Poking this area might suffice for some initial
> testing to check
On Wed, Sep 10, 2014 at 12:43 PM, Robert Haas wrote:
> On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva wrote:
> > I'm continuously studying Postgres codebase. Hopefully I'll be able to
> make
> > some contributions in the future.
> >
> > For now I'm intrigued about the extensive use of memory alig
On Wed, Sep 10, 2014 at 4:29 PM, Bruce Momjian wrote:
> On Wed, Sep 10, 2014 at 11:43:52AM -0400, Robert Haas wrote:
>> But there are a couple of obvious problems with this idea, too, such as:
>>
>> 1. It's really complicated and a ton of work.
>> 2. It would break pg_upgrade pretty darn badly unl
On Wed, Sep 10, 2014 at 11:43:52AM -0400, Robert Haas wrote:
> But there are a couple of obvious problems with this idea, too, such as:
>
> 1. It's really complicated and a ton of work.
> 2. It would break pg_upgrade pretty darn badly unless we employed some
> even-more-complex strategy to mitigat
On Tue, Sep 9, 2014 at 10:08 AM, Arthur Silva wrote:
> I'm continuously studying Postgres codebase. Hopefully I'll be able to make
> some contributions in the future.
>
> For now I'm intrigued about the extensive use of memory alignment. I'm sure
> there's some legacy and some architecture that re
On Tue, Sep 9, 2014 at 11:08:05AM -0300, Arthur Silva wrote:
> I'm continuously studying Postgres codebase. Hopefully I'll be able to make
> some contributions in the future.
>
> For now I'm intrigued about the extensive use of memory alignment. I'm sure
> there's some legacy and some architectur
13 matches
Mail list logo
