On 2013-01-09 15:07:10 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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 prepared). > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
