On Mon, 2005-10-03 at 23:25 +0200, Martijn van Oosterhout wrote:
> Possible problem with caching:
> if you're called by the system qsort, can you assume anything about the
> order of the comparisons?
That applies only to the non-external sort case, which I'm not trying to
improve with these suggestions. (No, you can't assume that, it was
a heapsort only suggestion).
> Please note: if inlineApplySortFunction() is actually inlined (it isn't
> by default)
Can you explain your last post some more. Thats not what I get.
> > is a subset of the PK (a typical one-many relationship) and groupings
> > also. In the majority of cases, these attrs are at the start of a tuple.
> > The *_getattr macros are particularly poor at handling NULLs. When
> > *_getattr sees *any* NULL is present for a tuple it checks the
> > nullability of all attrs up to the current attrnum before returning
> > using the cached offsets. The macro could be altered so that if the
> > current attrnum < firstNullableAttrnum (which we can set once for the
>
> Maybe easier, in the macro use: bitmap & ((1<<attnum)-1) to quickly
> check that no nulls precede the value we're looking for and hence we
> can use the fast path anyway. Along the lines of:
You may be right, the exact code that brings the right benefit is
somewhat trickier than spotting the opportunity.
> Mind you, if you start creating seperate routines for different cases
> you can go a long way. Elsewhere on this list I created a special case
> for single-key integer index columns and got an 8% speed increase. Not
> exactly a viable solution though.
But an interesting one. Once we've done everything else, that use case
is close to the top of my list, if the performance gain was still as
useful, all other things considered.
Best Regards, Simon Riggs
