Да, могут быть и минусы. Если другой запрос просматривает другой сегмент данных, не определенный по дате, это может привести к снижению производительности, если строки теперь распределены по большему количеству страниц данных. Точно так же, как ваш первый запрос прибыли. Это полностью зависит от информации не в вашем вопросе.
другие запросы, использующие PK таблицы (скажем, id_foo)
Это может быть что угодно . Это зависит от того, что вы есть и что вы запрашиваете точно . На запрос одной строки это никак не влияет, но может быть несколько строк.
Имейте в CLUSTER
виду, что перезаписывает таблицу в первоначальном состоянии, как это VACUUM FULL
делает (удаляет мертвые кортежи, сжимает физический размер таблицы, переписывает индексы). Таким образом, вы можете сразу увидеть положительный эффект на производительность чтения независимо от порядка сортировки. (Как и в случае с вами VACUUM FULL
.)
После CLUSTER
этого вы, возможно, захотите запустить простую VACUUM
таблицу, чтобы обновить карту видимости , что может разрешить сканирование только по индексу.
Все преимущества CLUSTER
сжатия с частотой записи.
Кроме того, если у вас много обновлений в таблице, это CLUSTER
может существенно снизить производительность записи, удалив «пространство для маневра» для обновлений HOT на той же странице данных. Вы могли бы противостоять этому эффекту с FILLFACTOR
настройкой ниже 100. Опять же, это зависит от местоположения обновленных строк и т. Д.
Связанные с:
В любом случае, я бы, вероятно, не включал индексирование и кластеризацию my_timestamp::date
, а включал my_timestamp
напрямую. Ничего не потеряно, что-то получено. Актерский состав очень дешевый, но все равно дешевле его не использовать. И индекс может поддерживать больше запросов.
CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);
Несмотря на то , date
занимает всего 4 байта на диск и timestamp
занимает 8 байт, разница , как правило , теряются для выравнивания прокладки для вашего случая, и оба индекса имеет точно такой же размер.
Порядок нескольких строк в один и тот же день в результате индекса вашего выражения является произвольным. Еще может быть две одинаковые метки времени, но с 6 дробными цифрами, как правило, очень маловероятно. Помимо этого вы получаете детерминированный порядок строк, который может иметь различные преимущества.
Я также отбросил DESC
ключевое слово, поскольку Postgres может читать индексы задом наперед практически так же быстро, как и вперёд. (Порядок сортировки имеет значение для многоколоночных индексов!) Подробнее:
Вместо:
SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';
Вы бы теперь использовали:
SELECT * FROM foo
WHERE my_timestamp >= '2016-07-25' -- this is a timestamp literal now
WHERE my_timestamp < '2016-07-26';
Та же производительность.
Если вам не нужен компонент времени колонок на всех , преобразовать столбец в date
...
Как откатиться CLUSTER
?
CLUSTER
Для одной таблицы можно выполнить откат, ROLLBACK
как и для любой другой обычной команды, если транзакция не была зафиксирована.
Тем не менее, я цитирую руководство :
CLUSTER
без каких-либо параметров повторная кластеризация всех ранее кластеризованных таблиц в текущей базе данных, которой владеет вызывающий пользователь, или всех таких таблиц, если они вызваны суперпользователем. Эта форма CLUSTER
не может быть выполнена внутри блока транзакции.
Вы всегда можете запустить CLUSTER
с другим индексом, чтобы еще раз изменить физический порядок строк.
CLUSTER
? Нужно ли мне сейчасCLUSTER
использовать ПК?