В 10й, на самом деле. Несколько setof record в SELECT стали разворачиваться не в прямое их произведение, а в параллельный набор, в котором те, у которых недостаёт значений -- добиваются NULLами.

Но, понятно, что это лучшэ не трогать лишний раз.

У меня, например, (неоднократно) был такой опыт... и я даже и не знаю, что и ответить. ;)

Да уж, на такой вопрос хочется ответить - все зависит от задач)

Должностную инструкцыю, хе-хе.

Спасибо:)

в день примерно 30к записей, в теч полгода должно увеличиться в 2-2,5 раз, полей 22. По объему записей и структуры, таких таблиц 3 штук. Так как железа хорошие, пока проблем сейчас нет, корме отчетов, где скрипт долго отрабатывает из-за запросов с джойнами и объема данных.

Лучше бы Вы показали версию PostgreSQL, \d и \dt+ этой таблицы, и пару "типичных" запросов с их планами...

Если join не сложные и по вторичным ключам то все должно нормально отрабатывать, думаю стоит посмотреть на планы запросов и подумать насчёт индексов, записей не так много. У меня 300к в день прилетает и все норм, 27 полей и различные группировки.

Добрый день!

Подскажите пожалуйста, был индекс размером 27GB, все время только рост был по нему, не смотря на то, что в таблице есть и операции удаления. Стало интересно, удалил сейчас индекс и построил его заново, новый такой же индекс занимает теперь 21GB, разница 6GB (!)

Почему так происходит, вакуум же по идее должен проходить и подчищать удаленные записи, как в таблице, так и в индексе, или я не совсем правильно понимаю работу? Буду благодарен за помощь, спасибо! (И если есть у кого-то лучшие практики, как освобождать индекс в таких случаях, буду признателен)

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

для очистки места в таблице нужен вручную вызываемый vacuum full  
отдельно для индексов есть reindex , если не ошибаюсь, в 12 версии добавился reindex concurrently
что позволяет ужать индекс с минимальной блокировкой

> REINDEX применяется в следующих ситуациях:
....
Индекс стал «раздутым», то есть в нём оказалось много пустых или почти пустых страниц. Это может происходить с B-деревьями в PostgreSQL при определённых, достаточно редких сценариях использования. REINDEX даёт возможность сократить объём, занимаемый индексом, записывая новую версию индекса без «мёртвых» страниц

Да, я использовал именно не блокирующую перестройку индекса, просто хотелось бы как-то автоматизировать процесс. А подскажи пожалуйста, VACUUM FULL не блокирующий? Не хотелось бы прод положить на пару часов :) спасибо за советы

VACUUM FULL очень даже блокирующий )
насчет автоматизировать не подскажу, но вроде тут как-то прикладывали какие-то решения, вроде даже есть что-то в формате расширения, но сам я не использовал

Индексы - только REINDEX и/или DROP/CREATE для оптимизации места. В отличие от кучи (собственно данных) индекс не использует повторно освобождённые блоки (вроде в 12-й версии это полечили, или в 13-й? не помню).

👌буду копать в эту сторону, спасибо. А подскажи пожалуйста, чтобы быть уверенным, при удалении записи из таблицы большой, вакуум же автоматические старые версии (удаленные) подчищает, мне не нужно там вручную вакуум запускать?

👍спасибо! У меня 12.2, видимо не вылечили

Вот стартовая статья цикла про блокировки, но в ней есть ссылки на более другие циклы, в том числе и по индексам: https://habr.com/ru/company/postgrespro/blog/462877/
Я только не помню, Егор это нЪюанс освещал, или нет, о распухании индексов.

Автовакуум освобождает место только  в том случае, когда это место - в конце файла данных (как бы не вообще в самом конце финального файла данных).

Во всех остальных случаях место помечается, как свободное и доступное для записи, но в ОС/ФС оно не отдаётся.