Estou usando o postgresql 9.3 e tentando entender como e porque os índices são maiores que suas tabelas.
Exemplo de saída:
database_name | database_size | table_name | table_size | indexes_size | total_size
---------------+---------------+--------------------------------------------------------------+------------+--------------+------------
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_sends" | 57 MB | 131 MB | 189 MB
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_started" | 17 MB | 39 MB | 56 MB
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_stopped" | 16 MB | 35 MB | 51 MB
Estou executando a seguinte consulta para obter os tamanhos de tabela e índice.
SELECT
table_catalog AS database_name,
pg_size_pretty(pg_database_size(current_database())) As database_size,
table_name,
pg_size_pretty(table_size) AS table_size,
pg_size_pretty(indexes_size) AS indexes_size,
pg_size_pretty(total_size) AS total_size
FROM (
SELECT
table_catalog,
pg_database_size(current_database()) AS database_size,
table_name,
pg_table_size(table_name) AS table_size,
pg_indexes_size(table_name) AS indexes_size,
pg_total_relation_size(table_name) AS total_size
FROM (
SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name, table_catalog
FROM information_schema.tables
) AS all_tables
ORDER BY total_size DESC
) AS pretty_sizes;
Minha consulta está correta? O que faria com que os índices fossem maiores?
Razões possíveis:
Índices numerosos e provavelmente sobrepostos na tabela; dê uma olhada com
\d
Às vezes, o inchaço devido à alta rotatividade de atualizações pode afetar mais os índices do que as tabelas, dependendo dos padrões de atualização. Examine o tamanho de cada índice individual para ver se faz sentido.
Índices GiST, se usados, podem ser bem grandes
Ao contrário do que eu pensava originalmente, isso não é um problema com
TOAST
o armazenamento fora de linha não sendo contado, poispg_table_size
incluiTOAST
tabelas.Observe que, se você estiver preocupado com o aumento do índice e decidir
REINDEX
alguns de todos os índices envolvidos, considere definir um não padrãoFILLFACTOR
primeiro se a tabela estiver sujeita a muitas atualizações (ou inserções + exclusões). Caso contrário, você sofrerá um impacto no desempenho de gravação porque o índice não tem espaço para inserir novos valores, portanto, forçará muitas divisões de página e será estruturado com menos eficiência.