Re: [HACKERS] Double sorting split patch
On Fri, Sep 16, 2011 at 3:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: That looks awfully complicated. I don't understand how that works. I wonder if two passes would be simpler? I doubt it becomes much simpler, but here it is. -- With best regards, Alexander Korotkov. double-sorting-split-0.2.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Double sorting split patch
On 17.09.2011 17:36, Alexander Korotkov wrote: On Fri, Sep 16, 2011 at 3:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: That looks awfully complicated. I don't understand how that works. I wonder if two passes would be simpler? I doubt it becomes much simpler, but here it is. Thanks! It does look a lot simpler that way, IMHO. I presume this didn't change the performance characteristics? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Double sorting split patch
On Sat, Sep 17, 2011 at 9:00 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Thanks! It does look a lot simpler that way, IMHO. I presume this didn't change the performance characteristics? On the tests I provided in the first letter difference seems to be insignificant. -- With best regards, Alexander Korotkov.
Re: [HACKERS] Double sorting split patch
On 15 September 2011 19:46, Alexander Korotkov aekorot...@gmail.com wrote: Proposed algorithm finds following splits by single pass on two arrays: one sorted by lower bound of interval and another sorted by upper bound of interval. Have you considered if further performance improvements could come from providing a qsort implementation that allows for the inlining of the comparator? 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. Here's a macro-based inlining implementation: http://www.corpit.ru/mjt/qsort.html 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: http://www.lemoda.net/c/inline-qsort-example/index.html It's actually C++, but that isn't significant (c stdlib qsort() is called). When I built this code with GCC 4.5, the results were: C quick-sort time elapsed: 3.24 Inline C quick-sort time elapsed: 2.01 It looks like this is something that could be revisited. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
And as I said - David showed interests and we sometimes talk about it too. I never wanted to bother hackers with all this stuff. Actually, I would be very interested to see you post reports before/after each meeting either on -hackers or pgsql-sql. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
On Sat, Sep 17, 2011 at 5:57 PM, Josh Berkus j...@agliodbs.com wrote: And as I said - David showed interests and we sometimes talk about it too. I never wanted to bother hackers with all this stuff. Actually, I would be very interested to see you post reports before/after each meeting either on -hackers or pgsql-sql. Well Susanne said that the drafts are not public information so maybe the things that *could* end up in a draft shouldn't be either, if so i agree with the idea of creating a private list for that -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Double sorting split patch
On Sat, Sep 17, 2011 at 9:09 PM, Peter Geoghegan pe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
