根据这个page http://www.postgresql.org/docs/current/static/indexes-examine.html在手册中，indexes don't need to be maintained。然而，我们运行的 PostgresQL 表的连续速率为updates, deletes and inserts随着时间的推移（几天），查询会显着下降。如果我们删除并重新创建索引，查询性能就会恢复。
我们正在使用开箱即用的设置。
我们测试中的表目前一开始是空的，后来增长到了 50 万行。
它有一个相当大的行（很多文本字段）。
We are searching based of an index, not the primary key（我已经确认索引正在被使用，至少在正常情况下）
该表被用作单个进程的持久存储。
在 Windows 上使用 PostgresQL 和 Java 客户端。
我愿意放弃insert and update performance以保持查询性能。
我们正在考虑重新构建应用程序，以便将数据分布在各种动态表中，从而允许我们定期删除和重建索引而不影响应用程序。然而，与往常一样，要让它发挥作用需要时间紧迫，我怀疑我们在配置或使用中缺少一些基本的东西。
我们考虑过forcing vacuuming and rebuild to run at certain times，但我怀疑locking period for such an action would cause our query to block。这可能是一个选项，但存在一些实时（3-5 秒的窗口）影响，需要对我们的代码进行其他更改。
附加信息：表和索引
CREATE TABLE icl_contacts
(
id bigint NOT NULL,
campaignfqname character varying(255) NOT NULL,
currentstate character(16) NOT NULL,
xmlscheduledtime character(23) NOT NULL,
...
25 or so other fields. Most of them fixed or varying character fiel
...
CONSTRAINT icl_contacts_pkey PRIMARY KEY (id)
)
WITH (OIDS=FALSE);
ALTER TABLE icl_contacts OWNER TO postgres;
CREATE INDEX icl_contacts_idx
ON icl_contacts
USING btree
(xmlscheduledtime, currentstate, campaignfqname);
Analyze:
Limit (cost=0.00..3792.10 rows=750 width=32) (actual time=48.922..59.601 rows=750 loops=1)
-> Index Scan using icl_contacts_idx on icl_contacts (cost=0.00..934580.47 rows=184841 width=32) (actual time=48.909..55.961 rows=750 loops=1)
Index Cond: ((xmlscheduledtime < '2010-05-20T13:00:00.000'::bpchar) AND (currentstate = 'SCHEDULED'::bpchar) AND ((campaignfqname)::text = '.main.ee45692a-6113-43cb-9257-7b6bf65f0c3e'::text))
是的，我知道有各种各样的事情we could do to normalize and improve the design of this table。我们可能可以使用其中一些选项。
我这个问题的重点是关于理解how PostgresQL is managing the index and query over time (understand why, not just fix)。如果要重新进行或大幅重构，就会有很多变化。
