On 2014-10-08 13:52:14 -0400, Robert Haas wrote:
> On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Meh. Even "SELECT 1" is going to be doing *far* more pallocs than that to
> > get through raw parsing, parse analysis, planning, and execution startup.
> > If you can find a few hundred pallocs we can avoid in trivial queries,
> > it would get interesting; but I'll be astonished if saving 4 is measurable.
>
> I got nerd-sniped by this problem today, probably after staring at the
> profiling data very similar to what led Andres to ask the question in
> the first place. The gains are indeed not measurable on a
> macrobenchmark, but I had to write the patch to figure that out, so
> here it is.
>
> Although the gain isn't a measurable percentage of total runtime, it
> does appear to be a significant percentage of the palloc traffic on
> trivial queries. I did 30-second SELECT-only pgbench runs at scale
> factor 10, using prepared queries. According to perf, on unpatched
> master, StartTransactionCommand accounts for 11.46% of the calls to
> AllocSetAlloc. (I imagine this is by runtime, not by call count, but
> it probably doesn't matter much either way.) But with this patch,
> StartTransactionCommand's share drops to 4.43%. Most of that is
> coming from AtStart_Inval(), which wouldn't be hard to fix either.
Interesting - in my local profile AtStart_Inval() is more pronounced
than AfterTriggerBeginQuery(). I've quickly and in a ugly fashion hacked
AtStart_Inval() out of readonly queries ontop of your patch. Together
that yields a ~3.5% performance improvement in my trivial 'SELECT * FROM
tbl WHER pkey = xxx' testcase.
> I'm inclined to think that tamping down palloc traffic is worthwhile
> even if we can't directly measure the savings on a macrobenchmark.
> AllocSetAlloc is often at or near the top of profiling results, but
> there's rarely a single caller responsible for enough of those calls
> for to make it worth optimizing. But that means that if we refuse to
> take patches that save just a few pallocs, we're basically giving up
> on ever improving anything in this area, and that doesn't seem like a
> good idea either; it's only going to get slowly worse over time as we
> add more features.
I think it depends a bit on the callsites. If its somewhere that nobody
will ever care, because it's a slowpath, then we shouldn't care
either. But that's not the case here, so I do think that makes sense.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
