Greg Stark <gsstark@mit.edu> writes:
> I don't see how this is relevant though. One way or another postgres is going
> to have to sort strings in varying locales chosen at run-time. Comparing
> against strcoll's execution time without changing changing locales is a straw
> man.
No, it's not, because if we were to do our own implementation we could
avoid the need to do setlocale per se at all (inside the loop that is).
The trick is to expose the different locales as objects (pointed-to
structs) that can be passed to the strcoll function. The fundamental
difficulty is not so much with the libc innards as with the lousy API.
> I see no reason to think Postgres's implementation of looking up xfrm rules
> for the specified locale will be any faster than the OS's.
The point is that we can move that lookup out of the inner loop.
> An order of magnitude change in the cost for strcoll isn't really relevant
> unless the cost for strcoll is significant to begin with. I suspect strcoll
> costs are currently dwarfed by the palloc costs to evaluate the expression
> already.
I don't have numbers for that at my fingertips, but I have measured it
in the past, and the comparison function *is* a significant part of the
total CPU cost in sorts.
regards, tom lane