Leandro, -----Mensagem Original----- From: pgbr-geral-requ...@listas.postgresql.org.br Sent: Monday, June 13, 2011 12:00 PM To: pgbr-geral@listas.postgresql.org.br
> Vixe, agora é que boiei mesmo. O que seria uma tabela primária, > então? Em que as tabelas do PostgreSQL diferem das do Sybase ou MS > SQL Server? Como assim uma tabela com chave primária *é* (em vez de > _ter_) índice? Sim, no SQL Server uma tabela do tipo clustered *é* fisicamente armazenada como um índice. http://msdn.microsoft.com/en-us/library/ms189051.aspx >>> As páginas de um índice pode ser percorrido seqüencialmente? >> No SQL Server e no SyBase, sim. > Em alguns casos, imagino, não em todos? No SQL Server e no SyBase, sim. > Me parece um argumento partindo dos resultados? continua faltando a > explicação que, implicitamente, pedi acima: como preservar eficiência > no caso geral quando se otimiza para um caso específico. O caso indicado não é específico. A regra é a tabela ter uma chave natural ou primária, e não o contrário. > ... por isso mesmo, nenhum sistema SQL que eu conheça ordena > tabelas a menos que comandado explícita e manualmente para isso. Eu te apresento então os SGBDs SQL Server e SyBase. Dúvidas? Consulte o site da Microsoft. > Um sistema onde isso ocorre, como era o caso dos navigacionais ou dos > grafos, tende a ser globalmente lento para escrita,... Só se você desconsiderar boa parte dos fatores relevantes, como a utilidade de uma tabela desordenada ou a atualização do índice correspondente, que também faz parte do processo de escrita. > Ainda estou para achar o tal artigo. Eu agradeceria muito um URI ou > outra indicação de como o encontrar. http://technet.microsoft.com/en-gb/library/cc917672.aspx > ... sempre que você trouxe essas reclamações > sobre o desempenho do PostgreSQL, pedimos mais informações, e você > nunca as trouxe ... Reconheço que enfatizei as conclusões e não os fatos que usei como base, por serem feitos em bases de clientes que, de fato, não posso publicar. Se preciso montar/publicar artigos a partir de bases públicas para poder expor opiniões aqui, coloque isso nas normas da lista então que saio em seguida ou só fico assistindo. > ... concluir tentativamente, como fazemos, que o problema é que tua > aplicação foi toda construída para MS SQL Server e apenas parcialmente > portada para PostgreSQL. O que é natural e humano, devido às lacunas > de conhecimento aparentes. Eis aí o ponto fundamental que precisa mudar nessa comunidade: enquanto se achar que o que funciona lento em PostgreSQL foi feito para outro BD, o progresso chega por acaso. Limitar os campos de pesquisa ou os pontos que precisam de melhora por conta disso só desmerece o produto e seu futuro. Sou contra essa visão de que o desenvolvimento precisa ser otimizado para o banco de dados, qualquer que ele seja. Caso haja otimizações que resultem em ganhos de ordens de magnitude (como é o caso por exemplo de indexed views), é de se esperar que outros bancos de dados ofereçam mecanismos para atingir desempenho similar. Não impliquei com o PostgreSQL porque planejamos fazer de um jeito ou de outro, muito pelo contrário, simplesmente constatamos que tudo o que nunca deu problema de desempenho nos outros bancos de dados empacava no PostgreSQL. Tudo o que observei dessas "empacadas" me faz acreditar que a organização de tabelas e índices que indiquei é uma forma de melhorar (e muito) o desempenho do banco de dados. Se não querem nem analisar por causa da fonte, só lamento. Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
