Greg Stark <st...@mit.edu> writes: > That said, to help in the case I described you would have to implement > the tapesort algorithm on the GPU as well.
I think the real problem would be that we are seldom sorting just the key values. If you have to push the tuples through the GPU too, your savings are going to go up in smoke pretty quickly ... FWIW, I tend to believe a variant of what Greg Stark said upthread: there would surely be some win from reducing the impedance mismatch for comparison functions. In concrete terms, there would be no reason to have tuplesort.c's myFunctionCall2Coll, and maybe not inlineApplySortFunction either, if the datatype-specific comparison functions had APIs that were closer to what sorting wants rather than following the general SQL-callable-function API. And those functions cost a *lot* more than a one-instruction comparison does. But it's very much more of a stretch to believe that inlining per se is going to do much for us, and even more of a stretch to believe that getting a separate processor involved is going to be a win. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers