Uh, obviously I meant causal relationship and not correlation. On 27 January 2012 13:37, Robert Haas <robertmh...@gmail.com> wrote: > 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.
Well, I don't think it's all that subjective - it's more the case that it is just difficult, or it gets that way as you consider more specialisations. As for what types/specialisations may not make the cut, I'm increasingly convinced that floats (in the following order: float4, float8) should be the first to go. Aside from the fact that we cannot use their specialisations for anything like dates and timestamps, floats are just way less useful than integers in the context of database applications, or at least those that I've been involved with. As important as floats are in the broad context of computing, it's usually only acceptable to store data in a database as floats within scientific applications, and only then when their limitations are well-understood and acceptable. I think we've all heard anecdotes at one time or another, involving their limitations not being well understood. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
