Em 02-09-2011 22:44, Tiago Adami escreveu: > Em 2 de setembro de 2011 20:52, Euler Taveira de Oliveira > <[email protected]> escreveu: >> Em 02-09-2011 16:49, Tiago Adami escreveu: >>> Algumas tabelas contém várias colunas com tipo VARCHAR(4000). Não >>> quero discutir se isto está certo, normalizado, com chaves naturais ou >>> algo assim, acontece que o sistema já roda em 2 SGBDs desta forma, e >>> se eu quiser migrar para o PostgreSQL ele deverá funcionar sem >>> alterações na estrutura. >>> >> Isso pode ser feito mas eu iria de campo TEXT. Veja que migrar de um SGBD >> para >> outro você não necessariamente precisa seguir a risca pois o uso de alguns >> tipos pode implicar em perda de performance em outros SGBDs. >> > > Entendo. A mudança para TEXT é bem vinda e será estudada. Mas se não > me falha a dedução o tipo TEXT do PostgreSQL é o mesmo LONG VARCHAR ou > CLOB de outros bancos, certo? Não haveria nenhuma diferença de > desempenho neste sentido? > LONG VARCHAR, sim. CLOB, não. Para o tamanho especificado (4000), o tipo TEXT é o mais adequado no PostgreSQL (vide large objects [1] e tipos caracteres [2]) pois a coluna será armazenada _inline_ na maioria dos casos ou em um tabela toast [3] em poucos casos. Além disso, VARCHAR(4000) é alguns ciclos de CPU mais lento do que o TEXT porque o PostgreSQL validará o tamanho da cadeia de caracteres ao manipular a coluna.
>> Poder especificar o _block size_ por tablespace já foi discutido no grupo de >> desenvolvimento mas ninguém chegou a mostrar que há algum benefício em >> fazê-lo. O que foi feito recentemente (>= 9.0), é poder especificar alguns >> parâmetros por tablespace (que tenham algum benefício comprovado) tais como >> seq_page_cost e random_page_cost. >> > > Também não vejo necessidade de modificar estes parâmetros uma vez que > uma das tabelas foi criada com a mesma estrutura, e eu ainda adicionei > o dobro de campos com mesmo tamanho e nenhum problema aconteceu. Tenho > por experiência o DB2 que exige que o tamanho de página seja calculado > considerando a soma dos tipos das colunas mais alguns bytes de > overhead[1] (não quero entrar em detalhes, por isto apenas cito o link > abaixo). > Não sei como o PostgreSQL trabalha neste sentido, e a minha maior > preocupação é saber quando o PostgreSQL irá requisitar um tablespace > com tamanho superior a 8KB (sendo esta a minha dúvida crucial). > Não irá. Tablespaces utilizam mesmo tamanho de bloco definido para todo $PGDATA. [1] http://www.postgresql.org/docs/current/static/largeobjects.html [2] http://www.postgresql.org/docs/current/static/datatype-character.html [3] http://www.postgresql.org/docs/current/static/storage-toast.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
