DBA: «Кто-то слишком много ест!»

[Kwisatz]

Сурово. Но мне кажется это никому не нужно. Сейчас на бд такую жесть вытворяют изза огромных харварных ресурсов, что диву даешься.

[Kilor]

Если взять много-много раз «огромных хардварных ресурсов», то внезапно может выясниться, что никакого бюджета не хватает. :)

[Kwisatz]

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

[koropovskiy]

del.

[crackpot]

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

[Kilor]

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

[crackpot]

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

[Kilor]

Вы же хотели «меньше точности за меньше магии». :)

[n_bogdanov]

Статья хорошая, но почему-то автор обходит вниманием расширение pgstattuple, которое позволяет делать тоже самое, но со 100% точностью.

[Kilor]

Как и pgstattuple, эта функция собирает данные страница за страницей и не следует ожидать, что её результат представляет мгновенный снимок всего индекса.

На таблице гигабайтного объема это достаточно дорого, плюс…

Функция pgstattuple получает блокировку отношения только для чтения.

… блокировки.

[n_bogdanov]

>… блокировки.
Какие блокировки? Там уровень блокировки такой же, как и у SELECT. Как раз говорится о том, что блокировок нет и результат может быть не точен. Однако он всё равно будет точнее, чем селект через pg_statistic, ибо статистика может запаздывать, так как автовакуум может задержать на другой таблице/быть отключен/не успевать.

[Kilor]

Тут вопрос — стоит ли наложение даже простейшей блокировки (которая может помешать какому-нибудь ALTER) и физическая вычитка всех страниц таблицы и выдавливание кжша получаемого прироста точности.

[DmitryKuzmenko]

я попытался это дело воспроизвести в Firebird. Поначалу, конечно, удивили смешные штуки типа 1<<14, видимо, автор решил выпендриться.
Однако, воспроизвести с первого раза не получилось, т.к. видимо, в первом же скрипте кусок begin/end выполняется не в одной транзакции. Иначе я генерацию кучи версий повторяющимся update объяснить не могу. В Firebird в одной транзакции хоть миллион раз можно сделать апдейт записи, но версия будет только одна.
Вывод — что-то не так в PostgreSQL с версионностью? :-)

[Kilor]

я попытался это дело воспроизвести в Firebird

Хм… а зачем, если все в статье жестко завязано на PostgreSQL, вплоть до физического представления записей?

[DmitryKuzmenko]

ну как бы тоже версионник.