Re: Remove hacks for old bad qsort() implementations?

> > How about always adding the TID as last key when using qsort for
create
> > index ?
>
> I think you misunderstood: that's what we do now.  I'm proposing
> removing it because I think it's probably useless.

Ah, sorry, I did not look at the code, and interpreted your comment as
some exceptional handling.
I think really randomly (regarding TID) ordering highly duplicate keys
is not such a good idea.
But the point is, it does not need to be exact. Basically sorted with a
few exceptions
and jumps, or sorted by blockid only would be ok. How random does our
qsort really return those tids ?

You wrote:
> However, oprofile is telling me that doing this is costing
> *significantly* more than just returning zero would do:
>
>   9081  0.3050 :    tuple1 = (IndexTuple) a->tuple;
>   3759  0.1263 :    tuple2 = (IndexTuple) b->tuple;
>                :
>                :    {
> 130409  4.3800 :        BlockNumber blk1 =
ItemPointerGetBlockNumber(&tuple1->t_tid);

So why is this ItemPointerGetBlockNumber so expensive ?

>  34539  1.1601 :        BlockNumber blk2 =
ItemPointerGetBlockNumber(&tuple2->t_tid);

Is it not correctly inlined ? Are the shifts for BlockNumber so
expensive ?
Or is this simply some oprofile overhead that is not real at all ?

Andreas