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