Re: Per-column collation

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per-column collation
Date: 2010-12-04 16:02:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-12-04 16:04:15 Re: Per-column collation
Previous Message Peter Eisentraut 2010-12-04 16:01:24 Re: Per-column collation