Comments 8
Уже второе упоминание на хабре про pg_reorg, отличный повод таки использовать его у себя на проекте. спасибо за статью
CREATE INDEX CONCURRENTLY on tokens (substr(token), 0, 8)
CREATE INDEX CONCURRENTLY on tokens (substr(token, 0, 8))
Кстати, интересно — будет ли такой индекс использоваться при простом запросе
WHERE token = '0123456789'
WHERE substr(token, 0, 8) = '01234567' AND token = '0123456789'
К сожалению, не будет.
Спасибо, исправил (скопировал опечатку с первоисточника).
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
UFO just landed and posted this here
Я так понимаю, что использование pg_reorg рационально только для тех таблиц, в которые уже не производится запись новых данных?
Sign up to leave a comment.
Управление растущими нагрузками в Postgres: 5 советов от Instagram