On Wed, Jan 09, 2013 at 11:22:06AM +0000, Simon Riggs wrote:
> On 24 December 2012 16:57, Amit Kapila <amit.kapila@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
