Como eu sei se o meu servidor PostgreSQL está usando o locale “C”?

Question

Eu estou tentando otimizar meu PostgreSQL 8.3 tabelas DB para o melhor de minha capacidade, e eu não tenho certeza se eu precisar usar varchar_pattern_ops para determinadas colunas onde estou realizando um LIKE contra os primeiros N caracteres de uma string . De acordo com a esta documentação , o uso de xxx_pattern_ops só é necessário " ... quando o servidor não utilizar o idioma padrão 'C'".

Alguém pode explicar o que isso significa? Como faço para verificar o que locale meu banco de dados está usando?

Answer 1

Atualmente algum locale [ docs ] apoio só pode ser fixado em tempo de initdb, mas acho que a via SET um relevantes para _pattern_ops podem ser modificados em tempo de execução, LC_COLLATE. Para ver os valores definidos você pode usar o href="http://www.postgresql.org/docs/8.3/static/sql-show.html" rel="noreferrer"> comando .

Por exemplo:

SHOW LC_COLLATE

índices _pattern_ops são úteis em colunas que construções uso padrão de correspondência, como LIKE ou regexps. Você ainda tem que fazer um índice regular (sem _pattern_ops) para fazer busca a igualdade em um índice. Então você tem que levar tudo isso em consideração para ver se você precisa de tais índices em suas tabelas.

Sobre o locale seja, é um conjunto de regras sobre ordenação de caracteres, formatação e coisas semelhantes que variam de idioma / país para outro idioma / país. Por exemplo, o local fr_CA (Francês no Canadá) podem ter algumas regras diferentes de classificação (ou modo de apresentação de números e assim por diante) do que en_CA (Inglês no Canadá.). A localidade padrão "C" é o POSIX compatível com os padrões localidade padrão. Somente estritas caracteres ASCII são válidos, e as regras de ordenação e formatação são principalmente aqueles de en_US (Inglês dos EUA)

Em computação, locale é um conjunto de parâmetros que define do usuário idioma, país e qualquer especial preferências variante que o usuário quer ver em sua interface com o usuário. Normalmente, um identificador de localidade consiste de pelo menos um identificador de idioma e um identificador de região.

Answer 2

psql -l

de acordo com manual

exemplo de saída:

                               List of databases
    Name     | Owner  | Encoding |   Collate   |    Ctype    | Access privileges
-------------+--------+----------+-------------+-------------+-------------------
 packrd      | packrd | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 postgres    | packrd | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0   | packrd | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/packrd        +
             |        |          |             |             | packrd=CTc/packrd
 template1   | packrd | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/packrd        +
             |        |          |             |             | packrd=CTc/packrd
(5 rows)

Answer 3

Há também uma outra maneira (supondo que você quiser vê-los, não modificá-los):

/var/lib/postgres/data/postgresql.conf Verifique arquivo Seguintes linhas devem ser encontrados:

# These settings are initialized by initdb, but they can be changed.
lc_messages = 'en_US.UTF-8'                     # locale for system error message strings
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting

Answer 4

OK, dos meus perusings, parece que essa configuração inicial

initdb --locale=xxx

 --locale=locale
       Specifies the locale to be used in this database. This is equivalent to specifying both --lc-collate and --lc-ctype.

basicamente especifica a localidade "default" para todos os banco de dados que você cria depois disso (ou seja, ele especifica as configurações para template1, que é o modelo padrão). Você pode criar novos bancos de dados com uma localidade diferente como esta:

Locale é diferente do que a codificação, você pode manualmente especificar -lo e / ou codificação:

 CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;

Se você quiser chamá-lo manualmente.

Basicamente, se você não especificá-lo, ele usa o padrão do sistema, o que quase nunca é "C".

Portanto, se seus show LC_COLLATE retorna algo diferente de "C" ou "POSIX", então você não está usando o standard C locale e você precisará especificar os xxx_pattern_ops para seus índices. Note também a ressalva que se você quiser usar o <, <=,>, ou> = operadores que você precisa para criar um segundo índice sem a bandeira xxx_pattern_ops (a menos que você estiver usando o locale padrão C em seu banco de dados, o que é raro ...). Por apenas == e LIKE (etc.), então você não precisa de um segundo índice. Se você não precisa LIKE então você não precisa o índice com xxx_pattern_ops, possivelmente, também.

Mesmo que seus índices são definidos para agrupar com o "default" como

CREATE INDEX my_index_name
  ON table_name
  USING btree
  (identifier COLLATE pg_catalog."default");

Este não é suficiente, a menos que o padrão é o "C" (ou POSIX, a mesma coisa) agrupamento, não pode ser usado para padrões como LIKE 'ABC%'. Você precisa de algo como isto:

CREATE INDEX my_index_name
  ON table_name
  USING btree
  (identifier COLLATE pg_catalog."default" varchar_pattern_ops);

Answer 5

Se você tem a opção ...

Você pode recriar o cluster de banco de dados com a localidade C.

Você precisa passar a localidade para initdb quando Inicializar sua instância Postgres.

Você pode fazer isso independentemente do que padrão do servidor ou local do usuário é.

Isso é um comando de administração de servidor, porém, não um banco de dados tarefa designers de esquema. O cluster contém todos os bancos de dados no servidor, e não apenas o que você está otimizando.

Ele cria um novo cluster, e não migrar qualquer um dos seus bancos de dados ou dados existentes. Isso seria um trabalho adicional.

Além disso, se você estiver em uma posição onde você pode considerar a criação de um novo cluster como uma opção, você realmente deve estar pensando em usar PostgreSQL 8.4 em vez disso, o que pode ter localidades por banco de dados , especificado no CREATE DATABASE declaração .