Bom, sim e não.
      Sim, você não deve colocar índices em qualquer tabela/coluna do banco.
O uso desse item deve ser limitado.
      Não, a forma de manter os "snapshots" dos dados não mudou nem deve
mudar. Mas o tratamento do mesmo já está muito mais eficiente que na versão
7. Mantendo o auto-vacuum ativado, é bem provável que, para a maioria dos
casos, seu índice estará atualizado. Principalmente na versão 8.3

2008/7/13 Mozart Hasse <[EMAIL PROTECTED]>:

> 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
>



-- 
William Leite Araújo
Analista de Banco de Dados - QualiConsult
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a