Эпизодический запуск pg_repack, даже раз в неделю, будет проносить профит: он сделает индексы компактнее и быстрее. Принесет ли профит кластеризация по индексу конкретно вам я не могу сказать, так как все зависит от ваших запросов.
Другого использования pg_repack не предусмотренно
И в том и в другом случае включен FPW (full page write), но средний размер записи в wal у bigserial меньше.
А происходит это потому что FPW записывается только после первой модификации страницы.
В случае с UUID — переиспользование буферов в буферном пуле маленькое и там мы пачкаем "новые" страницы чаще и чаще вызываем FPW.
Так что я оказался прав, запись WAL связана с вытеснением страниц из буфера, прав но отчасти :)
PostgreSQL проверяет области видимости и ему приходится таскать страницы из истории в случае с неравномерным индексом, поэтому хотелось показать насколько это важно — индекс по равномерным данным. Если вы историю будете хранить на медленном IO с неравномерным индексом — это вас погубит.
Речь о том как сделать так, что бы вычитка большого числа строк из таблицы работала ещё быстрее, при использовании индекса по полю с условно рандомным значением.
ну не совсем так, речь про эффективный кэш, стабильный buffer pool в котором лежат стабильные части "горячих" данных — последний день, месяц.
В других СУБД есть возможность Clustered indexes (MSSQL, MySQL, Oracle) со своими особенностями. В PostgreSQL такой важной возможности нет, есть CLUSTER и сторонний pg_repack, с чем живем то и обслуживаем.
Вы правы, я намерено выбрал самый неудачный для моего случая UUID v4. Согласен, что лучше использовать стандартные решения, или прокачивать их.
Но задача была не перепробовать все UUID, а показать насколько может тормозить индекс и почему. Дать повод разработчикам задуматься о том что недостаточно просто построить индекс, надо понимать как он будет работать и как его обслуживать в дальнейшем. Поэтому для примера добавил известные решения, что бы дать волю экспериментам :)
Select вызывает запись при обновлении страниц после hot-update
select всегда вызывает запись (переписывает страницы при full_page_write) если находит закомиченные в clog, но не помеченные как закомиченные данные в data.
Стоит обратить внимание, что по json просто нельзя собрать статистику.
А база, планер которой работает по весовой схеме, просто не может нормально работать без статистики.
ни колонок переменной длины, а содержит в основном значения типов integer и timestamp.
дело в движке:
каждый индекс живет своей отдельной жизнью от данных
каждое обновление строки не делает обновление по месту, а создает новую версию строки и для каждой новой версии появляется такая же новая запись в индексе.
обслуживание
обычно через concurrency создают такой же индекс и удаляют старый, были баги в 9.4 с репликами, когда новый индекс не подхватывался, сейчас устранено.
Эпизодический запуск pg_repack, даже раз в неделю, будет проносить профит: он сделает индексы компактнее и быстрее. Принесет ли профит кластеризация по индексу конкретно вам я не могу сказать, так как все зависит от ваших запросов.
Другого использования pg_repack не предусмотренно
alexeiivanov
И в том и в другом случае включен FPW (full page write), но средний размер записи в wal у bigserial меньше.
А происходит это потому что FPW записывается только после первой модификации страницы.
В случае с UUID — переиспользование буферов в буферном пуле маленькое и там мы пачкаем "новые" страницы чаще и чаще вызываем FPW.
Так что я оказался прав, запись WAL связана с вытеснением страниц из буфера, прав но отчасти :)
в случае с bigserial:
в случае с UUID v4
хм, вы правы, а тут я не прав, каюсь :)
запустил тест еще раз и после этого натравлю pg_waldump
привет alexeiivanov !
PostgreSQL проверяет области видимости и ему приходится таскать страницы из истории в случае с неравномерным индексом, поэтому хотелось показать насколько это важно — индекс по равномерным данным. Если вы историю будете хранить на медленном IO с неравномерным индексом — это вас погубит.
ну не совсем так, речь про эффективный кэш, стабильный buffer pool в котором лежат стабильные части "горячих" данных — последний день, месяц.
В других СУБД есть возможность Clustered indexes (MSSQL, MySQL, Oracle) со своими особенностями. В PostgreSQL такой важной возможности нет, есть CLUSTER и сторонний pg_repack, с чем живем то и обслуживаем.
Вы правы, я намерено выбрал самый неудачный для моего случая UUID v4. Согласен, что лучше использовать стандартные решения, или прокачивать их.
Но задача была не перепробовать все UUID, а показать насколько может тормозить индекс и почему. Дать повод разработчикам задуматься о том что недостаточно просто построить индекс, надо понимать как он будет работать и как его обслуживать в дальнейшем. Поэтому для примера добавил известные решения, что бы дать волю экспериментам :)
Спасибо, Григорий! Опечатку в тексте исправил, речь конечно была про row-level локи
select всегда вызывает запись (переписывает страницы при full_page_write) если находит закомиченные в clog, но не помеченные как закомиченные данные в data.
Стоит обратить внимание, что по json просто нельзя собрать статистику.
А база, планер которой работает по весовой схеме, просто не может нормально работать без статистики.
Но надеюсь скоро исправят, здесь smagen писал: http://akorotkov.github.io/blog/2015/09/07/jsonb_statistics/ для 10-ки точно еще актуально.
ну как откуда, в control-файле же информация про два checkpoint'а
потестили как быстро pg открывает коннект, поздравляю
dell precision 5510 — меняли бесплатно батарею с такой же проблемой (в гарантийный срок) в http://screspect.ru/
Николай, спасибо за статью!
Как можно решить с помощью envoy можно проблему пинания 504 от апстрима к апстриму?
дело в движке:
обычно через concurrency создают такой же индекс и удаляют старый, были баги в 9.4 с репликами, когда новый индекс не подхватывался, сейчас устранено.
Очень доступно и круто!