On 2013-01-09 15:07:10 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > Well, I *did* benchmark it as noted elsewhere in the thread, but thats
> > obviously just machine (E5520 x 2) with one rather restricted workload
> > (pgbench -S -jc 40 -T60). At least its rather palloc heavy.
> > Here are the numbers:
> > before:
> > #101646.763208 101350.361595 101421.425668 101571.211688 101862.172051 101449.857665
> > after:
> > #101553.596257 102132.277795 101528.816229 101733.541792 101438.531618 101673.400992
> > So on my system if there is a difference, its positive (0.12%).
> pgbench-based testing doesn't fill me with a lot of confidence for this
> --- its numbers contain a lot of communication overhead, not to mention
> that pgbench itself can be a bottleneck.
I chose it because I looked at profiles of it often enough to know
memory allocation shows up high in the profile (especially without -M
> I would like to know if other people get comparable results on other
> hardware (non-Intel hardware would be especially interesting). If this
> result holds up across a range of platforms, I'll withdraw my objection
> to making palloc a plain function.
I only have access to core2 and Nehalem atm, but FWIW I just tested it
on another workload (decoding WAL changes of a large transaction into
text) and I see improvements around 1.2% on both.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2013-01-09 22:28:35|
|Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)|
|Previous:||From: Andres Freund||Date: 2013-01-09 22:14:52|
|Subject: Re: [PATCH] unified frontend support for pg_malloc et al and
palloc/pfree mulation (was xlogreader-v4)|