マニュアルのこのページによると、 indexes don't need to be maintained. ただし、継続率が の PostgresQL テーブルで実行しており、時間の経過 (数日) に伴い、クエリの大幅な低下が見られますupdates。インデックスを削除して再作成すると、クエリのパフォーマンスが回復します。deletesinserts
すぐに使用できる設定を使用しています。
このテストのテーブルは、現在、空の状態で開始され、50 万行にまで増加しています。かなり大きな行 (多数のテキスト フィールド) があります。
私たちはsearching based of an index, not the primary key（少なくとも通常の条件下では、インデックスが使用されていることを確認しました）
テーブルは、単一プロセスの永続ストアとして使用されています。Windows で Java クライアントを使用して PostgresQL を使用する。
insert and update performanceクエリのパフォーマンスを維持するためにあきらめても構わないと思っています。
アプリケーションに影響を与えることなく定期的にインデックスを削除および再構築できるように、データがさまざまな動的テーブルに分散されるように、アプリケーションを再構築することを検討しています。ただし、いつものように、これを機能させるには時間がかかります。構成または使用法に基本的なものが欠けているのではないかと思います。
と を検討forcing vacuumingし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);
分析:
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)です。やり直しや大幅なリファクタリングを行うと、多くの変更が発生します。