(2014/01/30 8:29), Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> I could live with just stddev. Not sure others would be so happy. > > FWIW, I'd vote for just stddev, on the basis that min/max appear to add > more to the counter update time than stddev does; you've got > this: > > + e->counters.total_sqtime += total_time * total_time; > > versus this: > > + if (e->counters.min_time > total_time || e->counters.min_time > == EXEC_TIME_INIT) > + e->counters.min_time = total_time; > + if (e->counters.max_time < total_time) > + e->counters.max_time = total_time; > > I think on most modern machines, a float multiply-and-add is pretty > darn cheap; a branch that might or might not be taken, OTOH, is a > performance bottleneck. > > Similarly, the shared memory footprint hit is more: two new doubles > for min/max versus one for total_sqtime (assuming we're happy with > the naive stddev calculation). > > If we felt that min/max were of similar value to stddev then this > would be mere nitpicking. But since people seem to agree they're > worth less, I'm thinking the cost/benefit ratio isn't there. Why do you surplus worried about cost in my patch? Were three double variables assumed a lot of memory, or having lot of calculating cost? My test result showed LWlock bottele-neck is urban legend. If you have more fair test pattern, please tell me, I'll do it if the community will do fair judge.
Regards, -- Mitsumasa KONDO NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
