On Thu, Jun 27, 2013 at 10:12 PM, Josh Berkus <j...@agliodbs.com> wrote: > Yeah, I think that's be bigger question. Ok, I'll start working on a > new test case. Here's my thinking on performance tests: > > 1. run pgbench 10 times both with and without the patch. See if there's > any measurable difference. There should not be.
I don't even see the point in extensive empirical results. Empirical results are somewhat useful for measuring the cpu cycle cost when the optimization doesn't give any benefit. That should be one fairly simple test and my understanding is that it's been done and shown no significant cost. When the optimization does kick in it saves space. Saving space is something we can calculate the effect precisely of and don't need empirical tests to validate. I would still want to check that it actually works as expected of course but that's a matter of measuring the row sizes, not timing lengthy pgbench runs. Neither of these address Tom's concerns about API changes and future flexibility. I was assigned this patch in the rreviewers list and my inclination would be to take it but I wasn't about to overrule Tom. If he says he's ok with it then I'm fine going ahead and reviewing the code. If I still have commit bits I could even commit it. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
