2013/4/2 Alexsander Rosa <[email protected]> > > 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. >
Você está *quase* reproduzindo a técnica de armazenamento de atributos grandes (aka TOAST) na perspectiva da aplicação ;-). De fato, considerando apenas poucos bytes, não creio ser uma otimização com ganho relevante em cenários comuns e como já mencionado pelo Flávio, o custo computacional se torna evidente quando precisamos extrapolar uma típica página de dados (8kb por padrão), mas daí voltamos a discussão do toast. Ainda não li o artigo do depesz, mas nas conclusões, os testes parecem ratificar a insignificancia de tal otimização, certo? Que Leandro Dutra não me ouça, mas no cerne da aplicação, isso também poderia ser resolvido com chaves artificiais e sem o /overhead/ da decodificação, não? Abraço! -Leo -- Leonardo Cezar http://www.postgreslogia <http://postgreslogia.wordpress.com>.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
