On Wed, Jan 09, 2013 at 11:22:06AM +0000, Simon Riggs wrote: > On 24 December 2012 16:57, Amit Kapila <amit.kap...@huawei.com> wrote: > > Performance: Average of 3 runs of pgbench in tps > > 9.3devel | with trailing null patch > > ----------+-------------------------- > > 578.9872 | 573.4980 > > On balance, it would seem optimizing for this special case would > affect everybody negatively; not much, but enough. Which means we > should rekect this patch. > > Do you have a reason why a different view might be taken?
We've mostly ignored performance changes of a few percentage points, because the global consequences of adding or removing code to the binary image can easily change performance that much. It would be great to get to the point where we can reason about 1% performance changes, but we're not there. If a measured +1% performance change would have yielded a different decision, we should rethink the decision based on more-robust criteria. (Most of this was said in initial April 2012 discussion.) This patch is a tough one, because it will rarely help the most-common workloads. If it can reduce the tuple natts from 9 to 8, the tuple shrinks by a respectable eight bytes. But if it reduces natts from 72 to 9, we save nothing. It pays off nicely for the widest, sparsest tables: say, a table with 1000 columns, all but ten are NULL, and those non-NULL columns are near the front of the table. I've never seen such a design, but a few folks seemed to find it credible. I've failed to come up with a non-arbitrary reason to recommend for or against this patch, so I profess neutrality on the ultimate issue. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
