Comments 8
Уже второе упоминание на хабре про pg_reorg, отличный повод таки использовать его у себя на проекте. спасибо за статью
+1
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'
Если будет, то это очень круто!0
К сожалению, не будет.
0
Спасибо, исправил (скопировал опечатку с первоисточника).
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
+1
UFO just landed and posted this here
Я так понимаю, что использование pg_reorg рационально только для тех таблиц, в которые уже не производится запись новых данных?
0
Sign up to leave a comment.
Управление растущими нагрузками в Postgres: 5 советов от Instagram