Em 2 de abril de 2013 12:01, Leonardo Cezar <[email protected]> escreveu:
> On Tue, Apr 2, 2013 at 10:36 AM, Alexsander Rosa < > [email protected]> wrote: > >> > Entendo que a diferença seria apenas de espaço em disco mesmo. Use >> varchar e boa. >> >> Strings de até 126 bytes têm 1 byte de overhead (para o tamanho da >> String); strings maiores têm 4 bytes de overhead. >> Não seria um ganho de velocidade se o PostgreSQL armazenasse strings de >> 2, 4 e 8 bytes em tipos unsigned? >> Sei que existe o tipo "char" (com aspas) que fica armazenado em >> exatamente 1 byte. >> > > Hmm... não é assim que funciona. > > Todos os tipos de tamanho variável (inclua aí o char e deixe o toast fora > disso – já explico) compartilham uma mesma estrutura chamada varlena. Este > é o cabeçalho padrão para bytea, bpchar (vulgo char), cstrings, &ca e > possui a seguinte definição: > > estrutura Varlena > v_len[4] -- informações sobre o tamanho do dado armazenado; > v_dat[1] -- Início do array de armazenamento; > > Este tipo de estrutura é muito utilizado como um /pattern/ e basicamente > possibilita a extensibilidade de tipos, funcionalidade que seria inviável > com tipos unsigned – se não me engano v_len já foi inteiro num belo dia. > Tentei fazer o diff com tags antigos no git mas me perdi :-\ > > Quando vc cria um tipo de dados com restrição de comprimento, vc habilita > no catálogo o armazenamento com atttypmod ( > 0 – ver > pg_attribute.atttypmod). Este mesmo atributo é utilizado para operações de > validações com a constante VLHDRSIZE (depois confirmo este nome) que é o > tamanho do header da estrutura varlena. > > Esta arquitetura é histórica e existe desde dos primórdios do elefante e a > mudança certamente exigiria uma refatoração inclusive conceitual da coisa > toda. > > O "char" com aspas pra mim é novidade.... > > Abraço! > > -Leo > Na verdade a minha "viagem" foi pensando assim: imagine que você tem um "tipo de operação" com 5 letras A-Z (ex: VENDA, COMPR, DEVOL, etc) usado como FK em vários lugares. Eu fiquei pensando: considerando que isso vai ter uns 10 bytes no Varlena, não seria mais rápido se sua aplicação convertesse isso para um número de 4 bytes (ex: VENDA = 21x26⁴ 4x26³ 13x26² + 3x26 + 0 = 9596496 + 70304 + 8788 + 78 + 0 = 9675666) e usasse este número como FK ao invés de um text? A codificação/decodificação seria em nível de aplicação/apresentação. Eu nunca usei isso, mas fiquei pensando vendo este overhead do Varlena, que pode ser um exagero em strings pequenas. -- Atenciosamente, Alexsander da Rosa
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
