On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis <pg...@j-davis.com> wrote: > After talking with a few people at PGCon, small noisy differences in CPU > timings can appear for almost any tweak to the code, and aren't > necessarily cause for major concern.
I agree with that in general, but the concern is a lot bigger when the function is something that is called everywhere and accounts for a measurable percentage of our total CPU usage on almost any workload. If memory allocation got slower because, say, you added some code to regexp.c and it caused AllocSetAlloc to split a cache line where it hadn't previously, I wouldn't be worried about that; the next patch, like as not, will buy the cost back again. But here you really are adding code to a hot path. tuplesort.c does its own accounting, and TBH that seems like the right thing to do here, too. The difficulty is, I think, that some transition functions use an internal data type for the transition state, which might not be a single palloc'd chunk. But since we can't spill those aggregates to disk *anyway*, that doesn't really matter. If the transition is a varlena or a fixed-length type, we can know how much space it's consuming without hooking into the memory context framework. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
