Início / dba / Perguntas / 89429
Accepted
Bohemian
Asked: 2015-01-16 16:49:59 +0800 CST

A pesquisa de índice seria visivelmente mais rápida com char vs varchar quando todos os valores forem 36 caracteres

  • 772

Eu tenho um esquema legado (isenção de responsabilidade!) Que usa um ID gerado com base em hash para a chave primária de todas as tabelas (existem muitas). Um exemplo desse id é:

922475bb-ad93-43ee-9487-d2671b886479

Não há esperança possível de mudar essa abordagem, no entanto, o desempenho com acesso ao índice é ruim. Deixando de lado a miríade de razões que isso pode ser, há uma coisa que notei que parecia menos do que ideal - apesar de todos os valores de id em todas as tabelas terem exatamente 36 caracteres de comprimento, o tipo de coluna é varchar(36), não char(36) .

A alteração dos tipos de coluna para comprimento fixo char(36)ofereceria algum benefício significativo de desempenho de índice, além do aumento muito pequeno no número de entradas por página de índice, etc.?

Ou seja, o postgres executa muito mais rápido ao lidar com tipos de comprimento fixo do que com tipos de comprimento variável?

Por favor, não mencione a minúscula economia de armazenamento - isso não será importante em comparação com a cirurgia necessária para fazer a alteração nas colunas.

postgresql performance

1 respostas

  1. Best Answer

    Não. Nenhum ganho . O manual afirma explicitamente :

    Dica: Não há diferença de desempenho entre esses três tipos , além do aumento do espaço de armazenamento ao usar o tipo preenchido em branco e alguns ciclos extras de CPU para verificar o comprimento ao armazenar em uma coluna com restrição de comprimento. Embora character(n)tenha vantagens de desempenho em alguns outros sistemas de banco de dados, não há tal vantagem no PostgreSQL; na verdade, character(n)é geralmente o mais lento dos três por causa de seus custos adicionais de armazenamento. Na maioria das situações, text ou character varyingdeve ser usado em seu lugar .

    Ênfase em negrito minha.

    char(n)é um tipo amplamente desatualizado e inútil. Fique com varchar(n). Sem necessidade de impor um comprimento máximo, varcharou textsão um pouco mais rápidos, com menos complicações.

    Se todas as strings tiverem exatamente 36 caracteres de comprimento, não haverá economia de armazenamento de qualquer maneira, nem mesmo uma minúscula. Ambos têm exatamente o mesmo tamanho no disco e na RAM. Você pode testar com pg_column_size()(em uma expressão e em uma coluna da tabela).

    E se todas as strings devem ter 36 caracteres, faça-o textcom uma CHECK (length(col) = 36)restrição que imponha o comprimento exatovarchar(36) , não apenas impondo max. comprimento. Ver:

    Você não pediu outras opções , mas vou citar duas:

    1.COLLATION

    A menos que você esteja executando seu banco de dados com o agrupamento "C" . O agrupamento é frequentemente esquecido e possivelmente caro. Como suas strings não parecem ter significado em uma linguagem natural, provavelmente não há sentido em seguir COLLATIONregras. Relacionado:

    Extenso benchmark comparando (entre outros) o efeito de COLLATE "C"no desempenho:

    2. UUID

    Sua string parece suspeitamente com um UUID (32 dígitos hexadecimais separados por 4 delimitadores de maneira canônica). É muito mais eficiente armazenar UUIDs como uuidtipo de dados real: mais rápido de várias maneiras e ocupa apenas 16 bytes por UUID - em oposição a 37 bytes na RAM para char(36)ou varchar(36)(armazenado sem delimitadores, apenas os 32 caracteres definidores) ou 33 bytes em disco. Mas o preenchimento de alinhamento resultaria em 40 bytes de qualquer maneira em muitos casos.) COLLATIONtambém é irrelevante para o uuidtipo de dados.

    SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid

    Isso pode ser útil (últimos capítulos):

    Veja também:

    • 53

relate perguntas