Коллеги, хелп. postgresql 11 есть большая партицированная таблица. добавили партицию, создали

индекс ONLY на родительскую таблицу. далее создали индекс на партицию и прицепили родительскому индексу.

[code]CREATE INDEX CONCURRENTLY i_audit_messages_sectioned_y2021m07_on_operation_code_id ON audit_messages_sectioned_y2021m07(operation_code_id);
ALTER INDEX i_audit_messages_sectioned_on_operation_code_id ATTACH PARTITION i_audit_messages_sectioned_y2021m07_on_operation_code_id;[/code]

вроде все нормально пока и логично. создали партиций на 50 лет. потом одумались и удалили часть, тормозят запросы.

--- удаляли так, тут без проблем удалилось:

[code]ALTER TABLE audit_messages_sectioned DETACH PARTITION audit_messages_sectioned_y2021m07;
DROP INDEX IF EXISTS i_audit_messages_sectioned_y2021m07_on_operation_code_id;
DROP TABLE audit_messages_sectioned_y2021m07;[/code]

---- затем партиция понадобилась снова. создаем так. все нормально создается

[code]CREATE TABLE IF NOT EXISTS audit_messages_sectioned_y2021m07 PARTITION OF audit_messages_sectioned FOR VALUES FROM ('2021-07-01 00:00:00') TO ('2021-08-01 00:00:00');
CREATE INDEX CONCURRENTLY i_audit_messages_sectioned_y2021m07_on_operation_code_id ON audit_messages_sectioned_y2021m07(operation_code_id);[/code]

--- пытаемся приаттачить индекс

[code]ALTER INDEX i_audit_messages_sectioned_on_operation_code_id ATTACH PARTITION i_audit_messages_sectioned_y2021m07_on_operation_code_id;
ERROR: cannot attach index "i_audit_messages_sectioned_y2021m07_on_operation_code_id" as a partition of index "i_audit_messages_sectioned_on_operation_code_id"
DETAIL: Another index is already attached for partition "audit_messages_sectioned_y2021m07"[/code]

--- то есть он есть, его удаляли, пересоздавали, но он волшебно есть в родительской таблице
--- ну ок, есть и хорошо. смотрим как работает, а работает как-будто его нет

EXPLAIN select operation_code_id from audit_messages_sectioned_y2021m07 order by operation_code_id;
QUERY PLAN
--------------------------------------------------------------------------------------------
Sort (cost=715.46..729.36 rows=5560 width=4)
Sort Key: operation_code_id
-> Seq Scan on audit_messages_sectioned_y2021m07 (cost=0.00..369.60 rows=5560 width=4)
(3 rows)

--- а его дружок, с которым это не выделывали работает нормально

[code]EXPLAIN select operation_code_id from audit_messages_sectioned_y2021m08 order by operation_code_id;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Only Scan using i_audit_messages_sectioned_y2021m08_on_operation_code_id on audit_messages_sectioned_y2021m08 (cost=0.56..1048590.12 rows=40380104 width=4)
(1 row)[/code]

отбросим в негодовании вопрос "Кто виноват?" (прошлые админы), а обратимся к вопросу "Что делать?"

>а обратимся к вопросу "Что делать?" Прекратить партицыонировать таблицу с жалкими 5 млрд значений. Но это так. А про скорость запроса у нас есть закреп: https://t.me/pgsql/303899 со списком начальной информацыи для разговора. И есть скрипт для получения этого всего одним скриптом: https://t.me/pgsql/476688 .

Кстати, уверяю вас — запросам глубоко безразлично, выполнен там attach index на родительскую или нет. Единственное, для чего attach index нужэн — чтобы он дропался вместе с родительским индэксом и не дропался сам по себе.

Вообще, можно конечно и так заметить, что реалистичных варианта почему неиспользуется конкретно этот индэкс конкретно в этом запросе два: или индэкс нетакой какой-то (недостроился ещё, например. Или на самом деле он другого типа) — или там на таблицу VACUUM не прошёл, и оно считает, что index-only по факту превратится просто в index scan, потому будет дольшэ. Но это всё... В общем, можэте попытаться разобраться сами, а нам — нужна информацыя из https://t.me/pgsql/303899 чтобы тут в угадайку не играть совсем уж.

даже после того как партицию отцепили?

Без разницы.

я думала, что индекс на партицию создается быстрее чем на всю таблицу. когда приаттачиваем как бы добавляем в общий индекс. но вопрос в другом. удалили партицию, создали ее же. индекс на партицию создали. а он в родительской уже как-бы есть, но как-бы нет. вот это вот проблема

Ещё раз — для скорости запросов это не проблема. Планировщику без разницы, куда индэкс приаттачен.

это понятно. но запрос индекса не видит. а в соседней партиции которую не удаляли - видит

Вообще, можэте \d+ на родительскую таблицу показать — посмотрим, что там куда из индэксов реально подцэплено. Но, реально, по вопросу скорости — вы нетуда копаете.

https://t.me/pgsql/509893

"i_audit_messages_sectioned_on_operation_code_id" btree (operation_code_id). есть в родительской, куда б он делся

Мне нужны не рассуждения, а \d+ . С рассуждениями вы ведь всё равно в непонятках каких-то, не так ли?

по моему я все что нужно изложила, и я не про скорость запроса. и не спросила совета партицировать или нет. я спросила почему индеск на партиции удалили, а потом создали, а приаттачить не дает как будто из родительской не удалялся. но его не использует.

основной вопрос в том, что при удалении партиции из словаря метаданных не все чистится. и как с этим бороться. версию указала. скорость запроса не при чем. вопрос в чистке метаданных.

Я неуверен в справедливости этого утверждения. Возможно, это так и там какой-то баг. Но вполне вероятно, что никакого бага нет — и реальная структура отличается от вашых представлений.

"Возможно, это так и там какой-то баг." это поняно сразу. вопрос что делать

"Когда программисты обвиняют комплиятор в ошыбке, обычно они делают сразу две ошыбки. Включая ту, в которой обвиняют компилятор"

(На самом деле, я подозреваю, что индэкс и так создался приаттаченным при создании партицыи. А вашэ ручное создание индэкса — только создало второй такой жэ. Но это потому, что у меня утро, кофе, и я занимаюсь безсмысленным гаданием на кофейной гуще.)

Вообще, жэлающие могут посмотреть в pg_catalog. — и выяснить, что там за индэкс приаттачен с таким именем, почему и где он лежыт и с каких времён остался. Тожэ метод, к тому жэ неплохая тренировка разборок с каталогом постгреса.

видимо у вас зародилось подозрение, что я туда не смотрела?

Никогда об этом не думал, и вообще это не относится к делу.

Неужели на препирательства в чате последние полчаса времени хватает, а на то, чтобы приложить \d+ - нет?

Небось, секретная структура таблиц.

С названиями колонок кириллицей

\d+ audit_messages_sectioned

Можно файлом

Так на pastebin кидайте, особенно если там много.

Или файлом, да. (Знаю людей, которые нелюбят, когда текст в телеге кидают файлом — но мне норм, например).