Come faccio a sapere se il mio server PostgreSQL sta usando il locale “C”?

Question

Sto cercando di ottimizzare i miei PostgreSQL 8.3 tabelle DB al meglio delle mie capacità, e sono sicuro se ho bisogno di usare varchar_pattern_ops per alcune colonne in cui sto eseguendo una LIKE contro i primi N caratteri di una stringa . Secondo questa documentazione , l'uso di xxx_pattern_ops è necessaria solo " ... quando il server non usa lo standard locale 'C'".

Qualcuno può spiegare cosa significa questo? Come posso controllare quello che dalla localizzazione mio database sta usando?

Answer 1

Al momento qualche locale [ docs ] supporto può essere impostato solo in caso di tempo initdb, ma penso che quello relativo al _pattern_ops può essere modificato tramite SET in fase di esecuzione, LC_COLLATE. Per vedere i valori impostati è possibile utilizzare il comando SHOW href="http://www.postgresql.org/docs/8.3/static/sql-show.html" rel="noreferrer">

Ad esempio:

SHOW LC_COLLATE

indici _pattern_ops sono utili nelle colonne che utilizzano costrutti modello corrispondenza, come LIKE o espressioni regolari. Hai ancora a fare un indice regolare (senza _pattern_ops) per fare ricerca su un indice uguaglianza. Quindi, si deve prendere in considerazione tutto questo per vedere se avete bisogno di tali indici sulle vostre tavole.

A proposito di ciò che locale è, è un insieme di regole sul carattere ordinamento, la formattazione e cose simili che variano da lingua / paese in un'altra lingua / paese. Per esempio, il locale fr_CA (francese in Canada) potrebbe avere alcune regole diverse di ordinamento (o modo di visualizzazione dei numeri e così via) che en_CA (inglese in Canada.). Il locale standard "C" è l'impostazione internazionale predefinita conforme agli standard POSIX. Solo rigorosi caratteri ASCII sono validi, e le regole di ordinamento e la formattazione sono per lo più quelli di en_US (inglese americano)

  

In informatica, locale è un insieme di   parametri che definiscono l'utente del   lingua, paese e qualsiasi danno speciale   preferenze variante che l'utente   vuole vedere nella loro interfaccia utente.   Di solito un identificatore locale è costituito   di almeno un identificatore di lingua e   un identificatore regione.

Answer 2

psql -l

in base al manuale

output di esempio:

                               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

C'è anche un altro modo (supponendo che si desidera controllare loro, non modificarli):

Controlla il file /var/lib/postgres/data/postgresql.conf linee seguenti dovrebbero trovare:

# 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, dai miei perusings, sembra che questa impostazione iniziale

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.

specifica in sostanza l'impostazione internazionale "default" per tutti i database che si crea dopo che (vale a dire che specifica le impostazioni per il template1, che è il modello predefinito). È possibile creare nuovi database con una diversa impostazione internazionale in questo modo:

Locale è diverso rispetto alla codifica, è possibile manualmente specificare e / o la codifica:

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

Se si desidera chiamare manualmente fuori.

In pratica se non si specifica che, utilizza il default del sistema, che è quasi mai "C".

Così, se il show LC_COLLATE restituisce qualcosa di diverso da "C" o "POSIX", allora non si sta utilizzando il standard C locale e sarà necessario specificare le xxx_pattern_ops per gli indici. Nota anche la che, se si desidera utilizzare il <, <=,>, o> = operatori è necessario creare un secondo indice, senza la bandiera xxx_pattern_ops (a meno che non si sta utilizzando la versione locale di serie C sul database, che è raro ...). Per soli == e LIKE (ecc), allora non è necessario un secondo indice. Se non avete bisogno di LIKE, allora non è necessario l'indice con xxx_pattern_ops, forse, pure.

Anche se gli indici sono definiti a raccogliere con il "default" come

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

Questo non è sufficiente, a meno che il valore predefinito è il "C" (o POSIX, stessa cosa) collazione, non può essere utilizzato per i modelli come LIKE 'ABC%'. Hai bisogno di qualcosa di simile:

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

Answer 5

Se hai la possibilità ...

Si potrebbe ricreare il cluster di database con la versione locale C.

È necessario passare il locale a initdb quando inizializzazione l'istanza Postgres.

Si può fare questo indipendentemente da ciò che di default del server o locale dell'utente è.

Questo è un comando di amministrazione del server, però, non è un database schema designer compito. Il cluster contiene tutti i database sul server, non solo quello che si sta ottimizzando.

Si crea un nuovo cluster di zecca, e non migra uno dei database o dati esistenti. Sarebbe lavoro supplementare.

Inoltre, se siete in una posizione in cui si può prendere in considerazione la creazione di un nuovo cluster come opzione, è in realtà dovrebbe essere considerato con PostgreSQL 8.4, invece, che può avere locali per-base di dati , specificati nel CREATE DATABASE dichiarazione .