>> А если нужен но мешает вот в этом конкретном запросе - то его можно отключить конструкциями типа "+0", >> правда я не в курсе работает ли этот хак на постгресе.
>>>> Нет хинтов в PostgreSQL. А индекс был добавлен еще давно и как раз было внезапно много данных.
Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Я не советовал пользоваться хинтами. Если упрощенно то select id, name from table where id = 10 заюзает индекс по ID.
Но если запрос написать в виде select id + 0 as id, name from table where id = 10 то индекс по ID уже использоваться не будет.
Далее надеюсь понятно как можно отключать индексы. Повторю - это в Firebird есть такая особенность оптимизатора. Сработает ли это в PG - не в курсе.
Почитал про EXPLAIN - оказалось что это план запроса так называется в PG. В Firebird оптимизатор поплоше чем в PG будет, но даже и в PG засады случаются, поэтому при написании запроса, если хоть сколько-то интересуют перспективы работы - просмотр получаемого плана обязателен. В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2013-04-04 01:13 am (UTC)>> правда я не в курсе работает ли этот хак на постгресе.
>>>> Нет хинтов в PostgreSQL. А индекс был добавлен еще давно и как раз было внезапно много данных.
Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Я не советовал пользоваться хинтами.
Если упрощенно то
select id, name from table where id = 10
заюзает индекс по ID.
Но если запрос написать в виде
select id + 0 as id, name from table where id = 10
то индекс по ID уже использоваться не будет.
Далее надеюсь понятно как можно отключать индексы.
Повторю - это в Firebird есть такая особенность оптимизатора. Сработает ли это в PG - не в курсе.
Почитал про EXPLAIN - оказалось что это план запроса так называется в PG.
В Firebird оптимизатор поплоше чем в PG будет, но даже и в PG засады случаются, поэтому при написании запроса, если хоть сколько-то интересуют перспективы работы - просмотр получаемого плана обязателен.
В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.