On 26-09-2012 14:52, Fábio Telles Rodriguez wrote: > Estou migrando uma base de 400GB de imagens (e mais uns 10GB de dados) para > Large Objects. Depois digo se melhorou ou não. Estou testando aqui. Sei que > para imagens pequenas, LO não deveria fazer muita diferença. > > Mas milhões de imagens em Bytea é um problema: quando você faz um select na > tabela, mesmo que não vá retornar o campo com bytea, se você fizer um seq > scan, você terá problemas, pois a imagem faz parte da tupla e percorrer > centenas de GB desnecessariamente não é nada bom. > bytea utiliza a estratégia TOAST [1]. Cada tupla terá no máximo 2 kB, então 10⁶ registros teremos no máximo ~ 2 GB na tabela principal (as imagens são armazenadas em arquivos toast). Só fica lento se o programador pregui^Z^Z^Z utilizar 'SELECT * ...'. Você pode testar várias variantes (vide comando ALTER TABLE SET STORAGE [2]) para atingir uma melhor performance ou melhor aproveitamento de espaço (compressão) com TOAST.
> No mais concordo: cada caso é um caso. Eu estou testando o meu caso > particular. Neste caso, o dump do bytea se mostrou inviável, pois leva muito > tempo e ocupa mais de 700GB, quase o dobro da base. > Mas você está desconsiderando os dados, certo? Além disso, você tem que considerar que imagem e alguns formatos não compactam quase nada; nestes casos, o tamanho da cópia de segurança certamente será maior do que o espaço dos arquivos em disco. [1] http://www.postgresql.org/docs/9.2/static/storage-toast.html [2] http://www.postgresql.org/docs/9.2/static/sql-altertable.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
