Peter Geoghegan <pe...@2ndquadrant.com> writes: > 1. What we should be doing with timsort, if anything. It is one > thing to demonstrate that it's a useful algorithm under certain > artificial conditions, but quite another to argue for its inclusion in > Postgres, or for it being selectively used at points where that is > likely to be a win, based on some criteria or another like known > cardinality, physical/logical correlation or assumed costs of > comparisons for each type. At the very least, it is an interesting > algorithm, but without integration that makes it actually serve user > needs, that's all it will ever be to us. Deciding if and when it > should be used is a rather nuanced process, and I'm certainly not > about to declare that we should get rid of quicksort. It does appear > to be a fairly good fit to some of our requirements though.
I kind of understood timsort would shine in sorting text in non-C collation, because of the comparison cost. So a test in some UTF8 collation or other would be interesting, right? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
