Alright, so while I agree with everything you've asked for, the fact is that there is a controversy in relation to binary bloat, and that's the blocker here. How can we satisfactorily resolve that, or is that question adequately addressed by the benchmark that I produced?
What if third party modules could include the template_qsort_arg.h header, and instantiate their own specialisation? The sort support function could either set an enum, or set a pointer to a qsort_arg specialisation, if there comparator was a little different, but still just a few instructions, as with float-based timestamps (I don't care enough about them to provide one in core, though). It would also essentially allow for user-defined sort functions, provided they fulfilled a basic interface. They may not even have to be comparison-based. I know that I expressed scepticism about the weird and wonderful ideas that some people have put forward in that area, but that's mostly because I don't think that GPU based sorting in a database is going to be practical. Why not add this capability to the SortSupport API, given that it wouldn't be very hard? The user would set the enum too, so it would appear in explain analyze output as "custom sort" or something like that. While a sorting specialisation of our qsort_arg is actually pretty close to optimal for scalar types and façades thereof, there could be a type that would benefit from using radix sort, for example, which isn't even comparison-based, and a user couldn't very well do that with the existing SortSupport API. I certainly don't care about this capability enough to defend it against any objections that anyone may have, especially at this late stage in the cycle. I just think that we might as well have it. -- 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