Re: [HACKERS] PATCH: two slab-like memory allocators
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] PATCH: two slab-like memory allocators |
Дата | |
Msg-id | 20170306224200.6eanapty52itdfj6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: two slab-like memory allocators (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | 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 по дате отправления: