Pessoal, Andei lendo a documentação http://wiki.postgresql.org/wiki/Introduction_to_VACUUM%2C_ANALYZE%2C_EXPLAIN%2C_and_COUNT e me deparei com esse parágrafo: (...) If you've read my past articles you'll recall that PostgreSQL's MVCC (Multi-Version Concurrency Control) does away with the need for expensive read locks by keeping multiple versions of table rows that have been updated, and not immediately removing deleted rows. This is done by storing 'visibility information' in each row. But for performance reasons, this information is not stored in indexes. This means that every time a row is read from an index, the engine has to also read the actual row in the table to ensure that the row hasn't been deleted. (...)
Se eu entendi direito, isso quer dizer que a forma como o Postgres armazena os dados para permitir acesso concorrente torna *muito* limitado o uso de índices (comparado a bancos de dados com index covering). Isso pode comprometer seriamente o desempenho nas consultas a tabelas grandes e com razoável taxa de atualização. Isso explica boa parte dos planos horríveis do Postgres 7, mas não sei até que ponto isso foi melhorado na versão 8. É isso mesmo ?! Há planos de se deixar isso mais eficiente em alguma versão futura? Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
