Skip site navigation (1) Skip section navigation (2)

index bloat on partial index 8.4

From: Kevin Ricords <kevin(at)silverback(dot)com>
To: <pgsql-admin(at)postgresql(dot)org>
Subject: index bloat on partial index 8.4
Date: 2011-10-03 17:07:06
Message-ID: 4E89EBBA.2070100@silverback.com (view raw or flat)
Thread:
Lists: pgsql-admin
Per documentation 
(http://www.postgresql.org/docs/8.4/static/routine-reindex.html):
In PostgreSQL 7.4 and later, index pages that have become completely 
empty are reclaimed for re-use. There is still a possibility for 
inefficient use of space: if all but a few index keys on a page have 
been deleted, the page remains allocated. So a usage pattern in which 
all but a few keys in each range are eventually deleted will see poor 
use of space. For such usage patterns, periodic reindexing is recommended.

My implementation is a 150 million row table with a partial index on 
newly created rows, where every row will be updated to not match the 
index condition every few minutes.
The index size appears to grow proportional to the number of rows added 
to the table, but doesn't shrink when rows are updated to no longer meet 
the partial index condition.

 >select relname, indexrelname, pg_relation_size(indexrelid) from 
pg_stat_user_indexes where relname = 't';
"t";"t_partial_idx";58064896

 >select count(1) from t where t_summarized=false;
34

Even if the 34 rows were each in different pages with a deep index 
structure, the index size is not justified, if I understand the 
documentation correctly.  I'd guess that 'completely empty' refers to 
whether the row exists, rather than whether the row belongs in the index.

Any ideas on this pattern of index bloat other than reindex/rebuilding 
periodically?  Has this been addressed in a newer release?

-Kevin


pgsql-admin by date

Next:From: Robert BurgholzerDate: 2011-10-03 17:10:59
Subject: Re: diagnosing a db crash - server exit code 2
Previous:From: Burgholzer, Robert (DEQ)Date: 2011-10-03 16:54:52
Subject: Re: diagnosing a db crash - server exit code 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group