Re: Encoding/collation question - Mailing list pgsql-general

From Tom Lane
Subject Re: Encoding/collation question
Date
Msg-id 24866.1576092317@sss.pgh.pa.us
Whole thread Raw
In response to Encoding/collation question  (Rich Shepard <rshepard@appl-ecosys.com>)
Responses Re: Encoding/collation question
List pgsql-general
Rich Shepard <rshepard@appl-ecosys.com> writes:
> My older databases have LATIN1 encoding and C collation; the newer ones have
> UTF8 encoding and en_US.UTF-8 collation. A web search taught me that I can
> change each old database by dumping it and restoring it with the desired
> encoding and collation types. My question is whether the older types make
> any difference in a single-user environment.

String comparisons in non-C collations tend to be a lot slower than
they are in C collation.  Whether this makes a noticeable difference
to you depends on your workload, but certainly we've seen performance
gripes that trace to that.

If your data doesn't require the larger character set of UTF8, then
using LATIN-any is going to offer some space savings (for non-ASCII
characters) plus minor performance benefits due to the lack of
variable-width characters.  This is less significant than the
collation issue, though, for most people.

            regards, tom lane



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fast, stable, portable hash function producing 4-byte or 8-byte values?
Next
From: Rich Shepard
Date:
Subject: Re: Encoding/collation question