Robert Haas <robertmh...@gmail.com> writes: > On Thu, Dec 1, 2011 at 11:44 AM, Peter Geoghegan <pe...@2ndquadrant.com> > wrote: >> Attached is revision of my patch with some clean-ups.
> One thing I'm starting to get a bit concerned about is the effect of > this patch on the size of the resulting binary. Regardless of that, I'm still of the opinion that this patch is fundamentally misdesigned. The way it's set up, it is only possible to have a fast path for types that are hard-wired into tuplesort.c, and that flies in the face of twenty years' worth of effort to make Postgres an extensible system. I really don't care about performance measurements: this is not an acceptable design, period. What I want to see is some mechanism that pushes this out to the individual datatypes, so that both core and plug-in datatypes have access to the benefits. There are a number of ways that could be attacked, but the most obvious one is to invent additional, optional support function(s) for btree opclasses. I also still think that we should pursue the idea of a lower-overhead API for comparison functions. It may be that it's worth the code bulk to have an inlined copy of qsort for a small number of high-usage datatypes, but I think there are going to be a lot for which we aren't going to want to pay that price, and yet we could get some benefit from cutting the call overhead. A lower-overhead API would also save cycles in usage of the comparison functions from btree itself (remember that?). I think in particular that the proposed approach to multiple sort keys is bogus and should be replaced by just using lower-overhead comparators. The gain per added code byte in doing it as proposed has got to be too low to be reasonable. 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