старинной версии гигов на 200 (DB1), которую я пробую проапгрейдить до текущей версии. После апгрейда (DB2) всё внешне работает норм, однако, если сделать pg_dumpall и восстановить это на чистой базе данных (после initdb) (DB3), начинает дичайше тормозить некий SQL-запрос по открытию тикета, 48 секунд вместо 1.5
Исключив влияние версий ПО и характеристик железа, подозрение пало на индексы.
Содержимое pg_indexes в DB2 и DB3 идентичное. Я заметил, что в DB2 (и DB3) не хватает некоторых индексов из DB1, однако, запрос в DB2 работает так, как будто на самом деле они есть. Могут ли индексы где-нибудь присутствовать в неявном виде, закешированными/скомпилированными, помимо pg_indexes?
Я с подозрением смотрю на некую pg_index, но пока слабо понимаю, что там.
Смотрите в список индексов таблицы. Возможно, надо просто сделать analyse базы.
> Есть RT старинной версии гигов на 200 (DB1), которую я пробую проапгрейдить до текущей версии. Какие версии PostgreSQL в этом участвуют (старая и новая), конкретно? > После апгрейда (DB2) всё внешне работает норм Каким образом осуществлялся upgrade? > если сделать pg_dumpall и восстановить это на чистой базе данных (после initdb) (DB3), начинает дичайше тормозить некий SQL-запрос по открытию тикета, 48 секунд вместо 1.5 Ну а и почему бы и нет — Вы VACUUM ANALYZE всех баз после этого сделали? > Я заметил, что в DB2 (и DB3) не хватает некоторых индексов из DB1 Такого не должно быть, казалось бы (разве что Вы с правами доступа "накосили" при дампе, восстановлении или при просмотре). > Могут ли индексы где-нибудь присутствовать в неявном виде, закешированными/скомпилированными, помимо pg_indexes? Там нет никаких индексов — это просто view (для удобства пользователей). ;) > Я с подозрением смотрю на некую pg_index, но пока слабо понимаю, что там. А вот это, как раз — настоящий системный каталог, на основании которого сделан view pg_indexes.
Обсуждают сегодня