On 21.09.2011 18:46, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 09/21/2011 10:50 AM, Tom Lane wrote:
The other question that I'm going to be asking is whether it's not
possible to get most of the same improvement with a much smaller code
footprint. I continue to suspect that getting rid of the SQL function
impedance-match layer (myFunctionCall2Coll etc) would provide most of
whatever gain is to be had here, without nearly as large a cost in code
size and maintainability, and with the extra benefit that the speedup
would also be available to non-core datatypes.
Can we get a patch so we can do benchmarks on this?
Well, we'd have to negotiate what the API ought to be. What I'm
envisioning is that datatypes could provide alternate comparison
functions that are designed to be qsort-callable rather than
SQL-callable. As such, they could not have entries in pg_proc, so
it seems like there's no ready way to represent them in the catalogs.
The idea that I was toying with was to allow the regular SQL-callable
comparison function to somehow return a function pointer to the
alternate comparison function, so that the first comparison in a given
sort run would be done the traditional way but then we'd notice the
provided function pointer and start using that. It would not be too
hard to pass back the pointer using FunctionCallInfoData.context, say.
The downside is adding cycles to unoptimized cases to uselessly check
for a returned function pointer that's not there. Perhaps it could be
hacked so that we only add cycles to the very first call, but I've not
looked closely at the code to see what would be involved.
You could have a new function with a pg_proc entry, that just returns a
function pointer to the qsort-callback.
Or maybe the interface should be an even more radical replacement of
qsort, not just the comparison function. Instead of calling qsort,
tuplesort.c would call the new datatype-specific sort-function (which
would be in pg_proc). The implementation could use an inlined version of
qsort, like Peter is suggesting, or it could do something completely
different, like a radix sort or a GPU-assisted sort or whatever.
--
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
