On ons, 2010-11-24 at 22:22 +0200, Peter Eisentraut wrote: > On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote: > > * Did you see any performance regression by collation? > > I found a bug in lc_collate_is_c(); result >= 0 should be > > checked before any other checks. SearchSysCache1() here > > would be a performance regression. > > That code turned out to be buggy anyway, because it was using the > "result" cache variable independent of the collation parameter.
Since I don't have a short-term solution for this, I have ripped out the caching of C-ness for nondefault locales. > I did some profiling with this now. The problem is that this function > lc_collate_is_c() would need to cache the "C-ness" property for any > number of collations. Depending on what call pattern you expect or want > to optimize for, you might end up caching most of the pg_collation > catalog, which is actually the mandate of SearchSysCache, but the > profile shows that SearchSysCache takes a large chunk of the additional > run time. > > If I remove that branch altogether, that is, don't treat the C locale > specially at all in the nondefault collation case, then using non-C > locales as nondefault collation is almost as fast as using non-C locales > as default location. However, using the C locale as a nondefault > collation would then be quite slow (still faster that non-C locales). > > The solution would perhaps be a custom, lightweight caching system, but > I haven't thought of one yet. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
