Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 942BCB5D801 for ; Mon, 3 Oct 2011 14:12:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 99838-04 for ; Mon, 3 Oct 2011 17:12:18 +0000 (UTC) X-Greylist: delayed 00:05:05.470984 by SQLgrey-1.8.0-rc2 Received: from exsmtp.infoquest.com (pemexhub01.infoquest.com [65.61.37.201]) by mail.postgresql.org (Postfix) with ESMTP id C884BB5DBD0 for ; Mon, 3 Oct 2011 14:12:17 -0300 (ADT) Received: from [10.5.1.245] (208.111.250.195) by exsmtp.infoquest.com (65.61.37.200) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 3 Oct 2011 13:07:05 -0400 Message-ID: <4E89EBBA.2070100@silverback.com> Date: Mon, 3 Oct 2011 13:07:06 -0400 From: Kevin Ricords User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Subject: index bloat on partial index 8.4 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201110/14 X-Sequence-Number: 38466 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