https://opennet.ru/openforum/vsluhforumID3/115610.html После года разработки опубликована (https://www.postgresql.org/about/news/1894/) новая стабильная ветка СУБД PostgreSQL 11. Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2023 года. Основное внимание при подготовке новой ветки было уделено расширению функциональности в областях управления очень большими базами данных и разработки приложений для масштабируемой обработки больших данных.<br><br><br><br><br>Основные новшества (https://www.postgresql.org/docs/11/static/release-11.html):<br><br><br>- Добавлена возможность применения JIT-компиляции (Just-in-Time) для ускорения выполнения некоторых выражений в процессе обработки SQL-запроса. Например, JIT применим для ускорения выполнения выражений внутри блоков "WHERE", в выходных списках (target lists), агрегатных выражениях и проекциях. JIT также задействован для ускорения некоторых внутренних операций. Предложенный JIT-компилятор построен на основе наработок LLVM и для включения требует установки дополни https://opennet.ru/openforum/vsluhforumID3/115610.html#164 Fri, 26 Oct 2018 15:26:25 GMT &gt; Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я <br>&gt; рубал все их сессии, и пока не налезли опять, вакум проходил <br>&gt; но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и <br>&gt; к СВОИМ таблицам, короче бред какойто <br><br>Если дело в одной БД происходит и даже в разных схемах - бывает просто имена совпадают, допустим в вашей схеме (дефолтный public) есть таблица state и у него есть в его схеме таблица с тем же имененм, но в запросе указать схему чужой разраб забыл и обращается не к своей, потом получает не те колонки вылетает с софте ошибка и коннект с тразакцией теряется и висит бесконечно. <br> https://opennet.ru/openforum/vsluhforumID3/115610.html#163 Fri, 26 Oct 2018 13:42:06 GMT Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я рубал все их сессии, и пока не налезли опять, вакум проходил<br>но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и к СВОИМ таблицам, короче бред какойто<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#162 Fri, 26 Oct 2018 07:24:25 GMT &gt; Короче, нашел, в этой же базе но, вообще не имеюшее к этой <br>&gt; таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но <br>&gt; у него свои таблицы и к моей никогда не обращается!!!<br><br>Чужое приложение научили делать commit? Помогло?<br><br><br> https://opennet.ru/openforum/vsluhforumID3/115610.html#161 Fri, 26 Oct 2018 06:10:24 GMT Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#160 Tue, 23 Oct 2018 13:05:32 GMT А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#159 Tue, 23 Oct 2018 13:01:40 GMT Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.<br>T1 началась во время t1.<br>T2 началась в t1 + 1.<br>T3 : t1 + 2<br>T4 : t1 + 3.<br>Ну и т.д.<br>Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.<br>На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#158 Tue, 23 Oct 2018 12:32:49 GMT Блокировки тут не причём.<br>Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.<br>А vacuum full эти мёртвые кортежи убирает?<br>Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#157 Tue, 23 Oct 2018 11:40:49 GMT есть и много процессов, но разные строки, read commited,<br>в данном конкретном случае, 2-3 процесса, (плюс позанимался, добавил нужных индексов для других таблиц, в целом уменьшилась нагрузка на сервер), сделал<br>alter table set (autovacuum_vacuum_cost_limit = 1000);<br>alter table set (autovacuum_vacuum_cost_delay = 5);<br>теперь автовакум не висит постоянно, остановил все сервисы, сделал VACUUM FULL<br>через пол дня:<br>Кортежей доступно2130<br>&#171;Мертвых&#187; кортежей28101<br>vacuum verbose<br>найдено удаляемых версий строк: 0, неудаляемых - 30230,<br>какого хрена?, никто таблицу не блокирует<br>select * from pg_catalog.pg_locks l where l.relation=23037<br>пусто<br> https://opennet.ru/openforum/vsluhforumID3/115610.html#156 Tue, 23 Oct 2018 08:41:27 GMT Настройка стоимости операции для (авто)вакуума сделает тоже самое, только скрипты плодить и от Update-а отказываться не нужно будет.<br>