Re: Progress on fast path sorting, btree index creation time

Uh, obviously I meant causal relationship and not correlation.

On 27 January 2012 13:37, Robert Haas <robertmhaas(at)gmail(dot)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