Re: [HACKERS] PATCH: two slab-like memory allocators - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] PATCH: two slab-like memory allocators
Date
Msg-id 20170306224200.6eanapty52itdfj6@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] PATCH: two slab-like memory allocators  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2017-03-06 23:32:30 +0100, Tomas Vondra wrote:
> > > The question however is whether this won't make the optimization pointless.
> > > I also, wonder how much we save by this optimization and how widely it's
> > > used? Can someone point me to some numbers?
> > 
> > I don't recall any recent numbers.  I'm more than a bit doubful that it
> > really matters - it's only used for the results of aggregate/window
> > functions, and surely they've a good chunk of their own overhead...
> > 
> 
> And if the benefit is negligible, trying to keep the optimization might
> easily result in slowdown (compared to non-optimized code).

I doubt the branch is noticeable here, given that we're doing a memory
allocation otherwise.  Should also be decently predictable.

> But I'm puzzled why we haven't seen any reports of failures? I mean, doing
> sum(int4) is not particularly extravagant thing, if there really is an
> issue, shouldn't we see a lot of reports? What are we missing?

Reports about what? False positives causing crashes / wrong results?  I
think it's quite unlikely to actually trigger this in practice, because
you need a properly aligned pointer, and then the preceding header has
to to point to a bit pattern that's equal to the context - that's
presumably quite unlikely in practice.

Regards,

Andres



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] Logical replication existing data copy
Next
From: Andreas Karlsson
Date:
Subject: Re: [HACKERS] rename pg_log directory?