Início / coding / Perguntas / 77323888
Accepted
rwallace
Asked: 2023-10-19 20:47:10 +0800 CST

Por que as enumerações do Postgres ocupam 4 bytes?

  • 772

De acordo com https://www.postgresql.org/docs/current/datatype-enum.html

Um valor enum ocupa quatro bytes no disco.

Esta parece uma escolha estranha. É claro que os rótulos enum são mapeados para números inteiros de tamanho fixo para aumentar a velocidade, mas por que 4 bytes?

Na maioria das vezes, enums são usados ​​apenas para algumas opções; 1 byte seria suficiente.

É compreensível que os designers queiram atender a enumerações ocasionais maiores. Qual é o maior enum já visto na natureza? Posso imaginar um sendo usado, por exemplo, para o código do país. São 249 na última contagem; apenas mais alguns países ultrapassariam 1 byte. Posso ver a razão para torná-lo 2 bytes.

Mas por que 4? Alguém já usou um enum de banco de dados com mais de 65.536 casos? O Postgres realmente funciona com tantos?

database

1 respostas

  1. Best Answer

    Nos bastidores, um valor enum é a real, não an integer, e é por isso que ocupa quatro bytes. Veja o catálogo do sistema:

    \d pg_enum
              Table "pg_catalog.pg_enum"
    Column     │ Type │ Collation │ Nullable │ Default 
═══════════════╪══════╪═══════════╪══════════╪═════════
 oid           │ oid  │           │ not null │ 
 enumtypid     │ oid  │           │ not null │ 
 enumsortorder │ real │           │ not null │ 
 enumlabel     │ name │           │ not null │ 
Indexes:
    "pg_enum_oid_index" PRIMARY KEY, btree (oid)
    "pg_enum_typid_label_index" UNIQUE CONSTRAINT, btree (enumtypid, enumlabel)
    "pg_enum_typid_sortorder_index" UNIQUE CONSTRAINT, btree (enumtypid, enumsortorder)

    enumtypidé o OID do tipo de dados (de pg_type), enumsortorderé o valor real armazenado na tabela e enumlabelé o rótulo.

    Para entender por que realé usado, veja este exemplo:

    CREATE TYPE wealth AS ENUM ('poor', 'rich');

SELECT * FROM pg_enum WHERE enumtypid = 'wealth'::regtype;

  oid  │ enumtypid │ enumsortorder │ enumlabel 
═══════╪═══════════╪═══════════════╪═══════════
 35366 │     35364 │             1 │ poor
 35368 │     35364 │             2 │ rich
(2 rows)

    Até agora, isso não é muito surpreendente.

    ALTER TYPE wealth ADD VALUE 'billionaire';

SELECT * FROM pg_enum WHERE enumtypid = 'wealth'::regtype;

  oid  │ enumtypid │ enumsortorder │  enumlabel  
═══════╪═══════════╪═══════════════╪═════════════
 35366 │     35364 │             1 │ poor
 35368 │     35364 │             2 │ rich
 35370 │     35364 │             3 │ billionaire
(3 rows)

    Isso também está bem claro.

    ALTER TYPE wealth ADD VALUE 'millionaire' BEFORE 'billionaire';

SELECT * FROM pg_enum WHERE enumtypid = 'wealth'::regtype;

  oid  │ enumtypid │ enumsortorder │  enumlabel  
═══════╪═══════════╪═══════════════╪═════════════
 35366 │     35364 │             1 │ poor
 35368 │     35364 │             2 │ rich
 35370 │     35364 │             3 │ billionaire
 35371 │     35364 │           2.5 │ millionaire
(4 rows)

    Ah! Desde então 'millionaire' < 'billionaire', sua ordem de classificação deve estar entre 'rich'e 'billionaire'. Com um integer, teríamos que alterar a ordem de classificação 'billionaire'para 4 para abrir espaço para o novo rótulo. Mas isso é impossível, porque o valor interno de 3 pode já estar armazenado em alguma tabela em algum lugar, e certamente não podemos sair por aí reescrevendo todas essas tabelas.

    A resposta óbvia é usar um valor de ponto flutuante, para que possamos interpolar novos valores entre os existentes.

    Temos que "desperdiçar" quatro bytes, porque não existe um tipo de dados de ponto flutuante mais curto. Se você considerar que cada linha da tabela tem uma sobrecarga de 23 bytes e que muitos dos três bytes que você gostaria de salvar podem ser perdidos devido ao preenchimento causado por requisitos de alinhamento, você verá que o desperdício não é tão ruim assim.

    • 1

relate perguntas