Poderia uma maneira tabelas organizadas por índice pavimentado para COUNT mais rápido (*) SELECT FROM tabela

Question

Acho que é complicado para criar um gatilho apenas para obter os atuais total de linhas da tabela sem fazer COUNT (*) FROM tabela. Estou pensando se suas tabelas organizadas por índice planejadas para Postgres 8.5 poderia torná-lo possível?

Answer 1

Eu não teria pensado uma tabela organizada por índice seria necessariamente mais rápido para digitalizar para contar todas as tuplas visíveis. Logicamente, ele teria que passar pela mesma quantidade de dados, seja organizado de modo que os dados está em nós folha b-tree ou no formato de pilha existente.

Atualmente, os índices PostgreSQL somente armazenar [key, ctid] pares (essencialmente). (A ctid é essencialmente um "rowid" - número da página pilha e índice ponteiro linha tuple) Então você não pode contar as linhas na tabela apenas por ir através do índice, porque você precisa verificar [xmin, xmax] para cada tupla -. e que só é mantido com os dados, no heap

Você poderia colocar [xmin, xmax] no índice como sugestões bem-- para este surgem de tempos em tempos. Mas este incha os índices, e para ser útil todas as atualizações / exclusões teria que se certificar de que eles foram mantidos up-to-date, e que os problemas de causas, não menos importante porque o trabalho envolvido em fazer uma atualização agora se expandiu por alguma quantidade multiplicada pelo número de índices na tabela. No caso de índices pesados ??como em tsvector, ou os baseados em expressões usuário caros, isso pode demorar um pouco, e em alguns casos desagradáveis ??não funcionar em todos, com linhas aparecendo agora a ser ao vivo no índice, mas é morto no heap. E todo o ponto deste exercício era suposto ser para permitir que o banco de dados para confiar na informação live-ness no índice exclusivamente, se possível. Este custo será constituída mesmo se você estivesse atualizando um não-indexados column-- algo a equipe foi para algum esforço para acelerar em 8,3 (tuplas somente heap).

Suponho que uma possibilidade seria a índices de marca como possuindo, opcionalmente, [xmin, xmax] - por exemplo, única marca o índice pkey dessa forma. Em seguida, teria que haver mudanças planejador para descobrir quando isso era uma vantagem --- parece que um pouco de trabalho.

tabelas

Índice organizada, se eles funcionam como acredito que fazer em Oracle (e SQL Server, onde qualquer tabela com um índice de cluster é basicamente organizada por índice) de trabalho, armazenando [key, tuple] no índice de chave primária em vez (e presumivelmente [key, pkey] em todos os outros) - não ctid, nenhum heap. Assim, "tupla" conterá [xmin, xmax, cminmax, natts, ....] etc e você poderia satisfazer o "select count (*) da tabela" apenas fazendo a varredura do índice. Mas isso essencialmente da mesma forma como a digitalização dos tuplos na pilha --- eles não magicamente ocupam menos espaço, porque eles estão agora em um "índice".

AFAICT a principal razão para uma tabela organizada por índice é que uma pequena mesa com um índice primário de uma única tecla vai ocupar uma página em vez de 3, e varreduras de índice de chave primária pode ser um pouco mais rápido. Eu me lembro do conselho da Oracle relacionadas com a I foi dado para IOT foi que eles foram destinados para as tabelas de dimensão estáticas e não uso geral, em parte devido ao custo imposto na manutenção de índices secundários (Eu não acho Oracle armazena [ chave, pkey] nos índices secundários IOT, mas sim algum tipo de rowid alternativa).

Answer 2

Esta é a maneira datado, mas com PostgreSQL 9.2 você começa varreduras somente de índice que também pode executar count (*).

Veja também,

• é "count (*)" muito mais rápido agora?