Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 21.09.2011 18:46, Tom Lane wrote:
>> 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,
> You could have a new function with a pg_proc entry, that just returns a
> function pointer to the qsort-callback.
Yeah, possibly. That would be a much more invasive change, but cleaner
in some sense. I'm not really prepared to do all the legwork involved
in that just to get to a performance-testable patch though.
> 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.
No. In the first place, that only helps for in-memory sorts. In the
second, it would absolutely destroy our ability to change the behavior
of sorting ever again. Considering that we've added ASC/DESC, NULLS
FIRST/LAST, and collation support over the years, are you really
prepared to bet that the sort code will never need any more feature
upgrades? (This concern is in fact the source of my beef with the whole
inlining proposal to begin with, but allowing the inlining to occur into
third-party code that we don't control at all would be a hundred times
worse.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
