On 2014-10-08 13:52:14 -0400, Robert Haas wrote: > On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers