From: | "Zeugswetter Andreas OSB SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Remove hacks for old bad qsort() implementations? |
Date: | 2008-03-18 10:25:43 |
Message-ID: | E1539E0ED7043848906A8FF995BDA57902EB0CB7@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Manolo SupaMA | 2008-03-18 10:42:50 | CVS problems |
Previous Message | Dave Page | 2008-03-18 09:43:42 | Re: [COMMITTERS] pgsql: Enable probes to work with Mac OS X Leopard and other OSes that |