Re: Per-column collation - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Per-column collation
Date
Msg-id 1290630135.23791.9.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: Per-column collation  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: Per-column collation
List pgsql-hackers
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.

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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: function(contants) evaluated for every row
Next
From: Robert Haas
Date:
Subject: profiling pgbench