Rod Taylor <rod.tay...@gmail.com> writes:
> Does anybody have experience on the cost, if any, of making this change?
> Pg 8.3:
> Encoding: SQL_ASCII
> LC_COLLATE: en_US
> LC_CTYPE: en_US
> Pg 8.4:
> Encoding: SQL_ASCII
> Collation: en_US.UTF-8
> Ctype: en_US.UTF-8
Well, *both* of those settings collections are fundamentally
wrong/bogus; any collation/ctype setting other than "C" is unsafe if
you've got encoding set to SQL_ASCII. But without knowing what your
platform thinks "en_US" means, it's difficult to speculate about what
the difference between them is. I suppose that your libc's default
assumption about encoding is not UTF-8, else these would be equivalent.
If it had been assuming a single-byte encoding, then telling it UTF8
instead could lead to a significant slowdown in strcoll() speed ...
but I would think that would mainly be a problem if you had a lot of
non-ASCII data, and if you did, you'd be having a lot of problems other
than just performance. Have you noticed any change in sorting behavior?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
