Открыть список
Как стать автором
Обновить

Комментарии 15

Сурово. Но мне кажется это никому не нужно. Сейчас на бд такую жесть вытворяют изза огромных харварных ресурсов, что диву даешься.
Если взять много-много раз «огромных хардварных ресурсов», то внезапно может выясниться, что никакого бюджета не хватает. :)
Да я то со свой стороны согласен, я очень люблю оптимизацию, правильные наименования, красивые структуры данных, даже по схемам чтобы было красиво разложено. А потом прихожу в какую нить фирму а там ОБОЖЕЧТОЗАНАФИГ да к тому же на таких ресурсах жутких…
Как будто разные миры просто)

Красиво, руки почти что потянулись попытаться воспроизвести и сунуть в мониторинг. Но нет — не хорошо, когда в черную магию умеет кто-то один, а поддерживать ее — другим.
Нет ли заходов попроще? Пусть с меньшей точностью, но способных явно указать "эту таблу пора пересобрать"?

Ну как… Можно исходить из банальной оценки reltuples < relpages => плохо, точность уменьшится кратно, как и сложность.

На десятках миллионов строк, кажется, когда случится reltuples > relpages — это уже ну прям совсем поздно. :)

Вы же хотели «меньше точности за меньше магии». :)
Статья хорошая, но почему-то автор обходит вниманием расширение pgstattuple, которое позволяет делать тоже самое, но со 100% точностью.
Как и pgstattuple, эта функция собирает данные страница за страницей и не следует ожидать, что её результат представляет мгновенный снимок всего индекса.
На таблице гигабайтного объема это достаточно дорого, плюс…
Функция pgstattuple получает блокировку отношения только для чтения.
… блокировки.
>… блокировки.
Какие блокировки? Там уровень блокировки такой же, как и у SELECT. Как раз говорится о том, что блокировок нет и результат может быть не точен. Однако он всё равно будет точнее, чем селект через pg_statistic, ибо статистика может запаздывать, так как автовакуум может задержать на другой таблице/быть отключен/не успевать.
Тут вопрос — стоит ли наложение даже простейшей блокировки (которая может помешать какому-нибудь ALTER) и физическая вычитка всех страниц таблицы и выдавливание кжша получаемого прироста точности.
я попытался это дело воспроизвести в Firebird. Поначалу, конечно, удивили смешные штуки типа 1<<14, видимо, автор решил выпендриться.
Однако, воспроизвести с первого раза не получилось, т.к. видимо, в первом же скрипте кусок begin/end выполняется не в одной транзакции. Иначе я генерацию кучи версий повторяющимся update объяснить не могу. В Firebird в одной транзакции хоть миллион раз можно сделать апдейт записи, но версия будет только одна.
Вывод — что-то не так в PostgreSQL с версионностью? :-)
я попытался это дело воспроизвести в Firebird
Хм… а зачем, если все в статье жестко завязано на PostgreSQL, вплоть до физического представления записей?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
sbis.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре