KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> writes: > (2014/01/30 8:29), Tom Lane wrote: >> 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. [ shrug... ] Standard pgbench tests are useless for measuring microscopic issues like this one; whatever incremental cost is there will be swamped by client communication and parse/plan overhead. You may have proven that the overhead isn't 10% of round-trip query time, but we knew that without testing. If I were trying to measure the costs of these changes, I'd use short statements executed inside loops in a plpgsql function. And I'd definitely do it on a machine with quite a few cores (and a running session on each one), so that spinlock contention might conceivably happen often enough to be measurable. If that still says that the runtime cost is down in the noise, we could then proceed to debate whether min/max are worth a 10% increase in the size of the shared pgss hash table. Because by my count, that's about what two more doubles would be, now that we removed the query texts from the hash table --- a table entry is currently 21 doublewords (at least on 64-bit machines) and we're debating increasing it to 22 or 24. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers