La C
raccolta è la scelta giusta.
Tutto è un po 'più veloce senza impostazioni locali. E poiché nessuna fascicolazione è corretta, creare il database senza fascicolazione, ovvero con C
.
Potrebbe essere una seccatura dover fornire un confronto per molte operazioni. Tuttavia, non dovrebbe esserci una notevole differenza di velocità tra le regole di confronto predefinite e le regole di confronto ad hoc. Dopo tutto sono solo dati non ordinati e le regole di confronto vengono applicate durante l'ordinamento.
Tieni presente che Postgres si basa sulle impostazioni locali fornite dal sistema operativo sottostante, quindi devi avere locali generati per ogni locale da utilizzare. Più nella relativa risposta su SO qui e qui .
Tuttavia, come già accennato da @Craig , gli indici rappresentano il collo di bottiglia in questo scenario. Le regole di confronto dell'indice devono corrispondere alle regole di confronto dell'operatore applicato in molti casi che coinvolgono dati di carattere.
È possibile utilizzare l' COLLATE
identificatore negli indici per produrre indici corrispondenti. Gli indici parziali possono essere la scelta perfetta se si mescolano dati nella stessa tabella.
Ad esempio, una tabella con stringhe internazionali:
CREATE TABLE string (
string_id serial
,lang_id int NOT NULL
,string text NOT NULL
);
E sei principalmente interessato a una lingua alla volta:
SELECT *
FROM string
WHERE lang_id = 5 -- 5 being German / Germany here
AND string > 'foo' COLLATE "de_DE"
ORDER BY string COLLATE "de_DE";
Quindi creare indici parziali come:
CREATE INDEX string_string_lang_id_idx ON string (string COLLATE "de_DE")
WHERE lang_id = 5;
Uno per ogni lingua di cui hai bisogno.
In realtà, l' eredità potrebbe essere un approccio superiore per una tabella come questa. Quindi puoi avere un indice semplice su ogni tabella ereditata contenente solo stringhe per una singola locale. Ovviamente devi essere a tuo agio con le regole speciali per le tabelle ereditate.