Почему производительность запросов PostgresQL отбрасывает со временем, но восстановленный при восстановлении индекса

Согласно этой странице в руководстве, indexes don't need to be maintained. Однако мы работаем с таблицей PostgresQL, которая имеет непрерывный уровень updates, deletes и inserts это со временем (несколько дней) видит значительную неисправность запроса. Если мы удаляем и воссоздаем индекс, производительность запросов восстанавливается.

Мы используем из настроек поля.
Таблица в нашем тесте в настоящее время начинается пустой и растет до полумиллиона строк. Это ссорится (много текстовых полей).

Мы searching based of an index, not the primary key (Я подтвердил, что индекс используется, по крайней мере, при нормальных условиях),

Таблица используется в качестве персистентного хранилища для единственного процесса. Используя PostgresQL в Windows с клиентом Java.

Я готов сдаться 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). Если бы это должно было быть переделано или значительно пересмотрено, то было бы много изменений.