Qual é smallint ou character(10) mais eficiente?

Eu diria que adicionar um smallint artificial a chave primária seria mais barata em termos de espaço de armazenamento, se a tabela fosse cuidadosamente projetada.

Um smallint leva 2 bytes, enquanto um character(10) (que é, contra-intuitivamente, um varlena ) contendo caracteres ASCII, consumirá 14 bytes.

Na tabela, os 2 bytes extras seriam um desperdício, mas não esqueça que você terá um índice na coluna da chave primária. Portanto, o valor indexado será armazenado duas vezes:uma vez na tabela, uma vez no índice.

Para simplificar, vamos ignorar cabeçalhos de tupla e outras sobrecargas.

Usar o ISBN como chave primária custará 14 bytes extras por linha da tabela.
Adicionando um smallint a chave primária adicionará dois bytes à tabela e dois ao índice, perfazendo um total de quatro bytes adicionados.

Então adicionando um smallint chave primária deve economizar espaço .

Você não deve ignorar os problemas de alinhamento. Todos os tipos de dados são armazenados em endereços de memória que são múltiplos de certas potências de dois. Isso é exigido pelas arquiteturas dos processadores. Um smallint normalmente tem alinhamento 2, character tem alinhamento 1, enquanto por exemplo timestamp tem alinhamento 8.

Então, se sua tabela é definida como

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Então os dados da tabela ficariam assim:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

A linha é alinhada em um limite de 8 bytes e os seis bytes do final se id para o início de issue_time estará vazio “bytes de preenchimento”.

Então, para aproveitar ao máximo, você terá que considerar em qual ordem você define as colunas.

Por que tudo isso não é muito relevante na realidade:

Uma tabela com 5.000 ou 10.000 entradas é pequena, não importa o quê.

Qualquer gasto na otimização do espaço aqui é, na melhor das hipóteses, uma micro-otimização desnecessária.

Mas o que pode ser uma ideia inteligente na tabela de planejamento pode facilmente sair pela culatra mais tarde:Se – diferente do que você espera – você deseja armazenar 70.000 livros na tabela, você descobrirá que um smallint não será suficiente, mesmo se você permitir id negativo s. A dor que você terá que suportar quando tiver que alterar o tipo de dados de uma chave primária e todas as chaves estrangeiras que fazem referência a ela em um sistema ativo superam de longe qualquer prazer que você obtém ao economizar cerca de 100 KB por otimizações inteligentes.