O Cagrupamento é a escolha certa.
Tudo é um pouco mais rápido sem local. E como nenhum agrupamento está correto, crie o banco de dados sem agrupamento, ou seja, com C.
Pode ser uma dor ter que fornecer um agrupamento para muitas operações. Porém, não deve haver uma diferença notável na velocidade entre o agrupamento padrão e um agrupamento ad-hoc. Afinal, são apenas dados não classificados e as regras de ordenação são aplicadas na classificação.
Esteja ciente de que o Postgres se baseia nas configurações de localidade fornecidas pelo sistema operacional subjacente; portanto, é necessário gerar localidades geradas para cada localidade a ser usada. Mais respostas relacionadas ao SO aqui e aqui .
No entanto, como o @Craig já mencionado , os índices são o gargalo nesse cenário. O agrupamento do índice deve corresponder ao agrupamento do operador aplicado em muitos casos que envolvem dados de caracteres.
Você pode usar o COLLATEespecificador em índices para produzir índices correspondentes. Índices parciais podem ser a escolha perfeita se você estiver misturando dados na mesma tabela.
Por exemplo, uma tabela com cadeias internacionais:
CREATE TABLE string (
string_id serial
,lang_id int NOT NULL
,string text NOT NULL
);
E você está interessado principalmente em um idioma por vez:
SELECT *
FROM string
WHERE lang_id = 5 -- 5 being German / Germany here
AND string > 'foo' COLLATE "de_DE"
ORDER BY string COLLATE "de_DE";
Em seguida, crie índices parciais como:
CREATE INDEX string_string_lang_id_idx ON string (string COLLATE "de_DE")
WHERE lang_id = 5;
Um para cada idioma que você precisa.
Na verdade, a herança pode ser uma abordagem superior para uma tabela como esta. Em seguida, você pode ter um índice simples em cada tabela herdada contendo apenas cadeias de caracteres para um único código de idioma. Você precisa estar confortável com as regras especiais para tabelas herdadas, é claro.