Re: Double sorting split patch
От | Greg Stark |
---|---|
Тема | Re: Double sorting split patch |
Дата | |
Msg-id | CAM-w4HMOp6NEni02Z_P4sdqdOB4+k-_YX+Tty7z7k0+=0xG6oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Double sorting split patch (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Double sorting split patch
|
Список | pgsql-hackers |
On Sat, Sep 17, 2011 at 9:09 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > I find it curious that we go to the trouble of > providing a custom qsort implementation in qsort.c, pg_qsort, but > haven't gone one step further and considered inlining effects. I think we provided the qsort implementation for the benefit of platforms that didn't have a decent one and then ended up switching to use it always for some reason I don't recall. It wasn't because we thought we were better at writing qsort implementations than OS vendors. > I wondered in passing if compiler vendors had got around to figuring > out a way of solving the "inlining function pointer" problem that I > first read about years ago, so I ran this code, which benchmarks the > macro-based qsort above: You might need -fipa-pta or some other option. Or maybe LLVM would have a better chance of pulling this off. Compilers are usually pretty loath to generate specializations for every call site for fear of bloating the code. In any case I don't see how you're going to inline random database functions. Those are the cases where large amounts of data are being sorted. It's possible we sort small sets of data for internal reasons very frequently but I don't recall it turning up at the top of the profiles posted in recent days. Now a JIT that actually inlined random database functions into qsort and optimized the result would be pretty cool. But it doesn't seem like it's going to happen tomorrow... -- greg
В списке pgsql-hackers по дате отправления: