Re: Remove hacks for old bad qsort() implementations? - Mailing list pgsql-hackers

From Zeugswetter Andreas OSB SD
Subject Re: Remove hacks for old bad qsort() implementations?
Date
Msg-id E1539E0ED7043848906A8FF995BDA57902EB0CB7@m0143.s-mxs.net
Whole thread Raw
In response to Re: Remove hacks for old bad qsort() implementations?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Enable probes to work with Mac OS X Leopard and other OSes that
Next
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Enable probes to work with Mac OS X Leopard and other OSes that