On Thu, Jan 26, 2012 at 11:36 PM, Peter Geoghegan <pe...@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're doing 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers