On Thu, Jan 26, 2012 at 11:36 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> I'm not surprised that you weren't able to measure a performance
>> regression from the binary bloat. Any such regression is bound to be
>> very small and probably quite difficult to notice most of the time;
>> it's really the cumulative effect of many binary-size-increasing
>> changes we're worried about, not each individual one. Certainly,
>> trying to shrink the binary is micro-optimimzation at its finest, but
>> then so is inlining comparators. I don't think it can be
>> realistically argued that we can increasing the size of the binary
>> arbitrarily will never get us in trouble, much like (for a typical
>> American family) spending $30 to have dinner at a cheap resteraunt
>> will never break the budget. But if you do it every day, it gets
>> expensive (and fattening).
>
> Sure. At the risk of stating the obvious, and of repeating myself, I
> will point out that the true cost of increasing the size of the binary
> is not necessarily linear - it's a complex equation. I hope that this
> doesn't sound flippant, but if some naive person were to look at just
> the increasing binary size of Postgres and its performance in each
> successive release, they might conclude that there was a positive
> correlation between the two (since we didn't add flab to the binary,
> but muscle that pulls its own weight and then some).
I completely agree. So the point is that, when faced a patch that
adds an atypically large number of CPU instructions, we ought to ask
ourselves whether those instructions are pulling their weight. By way
of comparison, the latest posted version of Tom's generalized
index-only paths patch adds 14kB to the resulting executable (on my
Mac). Yours adds 55kB. We might ask ourselves whether the benefits
of this patch are four times greater than the benefits of Tom's patch.It's pretty hard to compare them directly since
they'redoing very
different things, and all of this is completely subjective, but I
doubt it. On the other hand, there is no rule that every byte of code
that gets committed must be made of solid gold, either. So, once
again: judgement call.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company