нет тупо запускал, помогало...теперь персетало помогать

Т.е. автовакуум умеет ещё и дефрагментировать?

всем привет, подскажите если в посгрес автовакуум уже не помогает освобождать место на диске, куда копать?

Автовакуум не освобождает место на диске. Освобождает VACUUM FULL

Автовакуум не освобождает место на диске. Освобождает VACUUM FULL

видимо это с остановкой в обслуживании ДБ?

видимо это с остановкой в обслуживании ДБ?

Или только конкретного отношения, если нужно оно. А вообще у меня есть патч - автосборщик мусора. Место не освободит но от раздувания отношения и индексов - предотвратит. Обращайся

нет тупо запускал, помогало...теперь персетало помогать

Что запускали?

Т.е. автовакуум умеет ещё и дефрагментировать?

Нет.

Нет.

Т.е. место не освобождается, просто постгрес может записывать в свободные места другие данные?

Т.е. место не освобождается, просто постгрес может записывать в свободные места другие данные?

https://postgrespro.ru/docs/postgrespro/10/routine-vacuuming

Т.е. место не освобождается, просто постгрес может записывать в свободные места другие данные?

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

нет тупо запускал, помогало...теперь персетало помогать

так он же авто… что значит запускали?)

а pg_repack не панацея в этом случае?

@avlepikhov Yaroslav спасибо

так он же авто… что значит запускали?)

точнее принудительно запускал Vacuum

1. вакуум-фулл - зло, только в крайнем случае 2. вакуум не освобождает место, он делает его доступным для перезаписи, поэтму после вакуума база меньше места на диске занимаеть не будет 3. читать документацию, плюс есть много позновательных статей на тему сборщика мусора в постгре. Вообще, сборщик мусора в постгре - это одна из самых сереьзных и сложных тем для освоения, с наскоку и по советам в этом чате Вы проблему не решите. в каждом случае все индивидуально. Ведь можно накрутить жесткие настройки для всей базы, от чего деградирует производительность, а можно найти конкретные таблицы-виновницы - и натравить автовакуум на них с агрессивными настройками

помогало после удалений в бд мусора. Сейчас не помогает

вот вообщем п.2

1. вакуум-фулл - зло, только в крайнем случае 2. вакуум не освобождает место, он делает его доступным для перезаписи, поэтму после вакуума база меньше места на диске занимаеть не будет 3. читать документацию, плюс есть много позновательных статей на тему сборщика мусора в постгре. Вообще, сборщик мусора в постгре - это одна из самых сереьзных и сложных тем для освоения, с наскоку и по советам в этом чате Вы проблему не решите. в каждом случае все индивидуально. Ведь можно накрутить жесткие настройки для всей базы, от чего деградирует производительность, а можно найти конкретные таблицы-виновницы - и натравить автовакуум на них с агрессивными настройками

вакуум сделает truncate файла таблицы при наличии пустых блоков справа. Он освобождает место, но только по случаю

Или только конкретного отношения, если нужно оно. А вообще у меня есть патч - автосборщик мусора. Место не освободит но от раздувания отношения и индексов - предотвратит. Обращайся

спасибо

вот для старта подробная статья

https://blog.2ndquadrant.com/autovacuum-tuning-basics/

вакуум сделает truncate файла таблицы при наличии пустых блоков справа. Он освобождает место, но только по случаю

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

но на живой базе это скорее исключение, особенно если это OLTP c интенсивным построчными DML

помогало после удалений в бд мусора. Сейчас не помогает

То есть, обычный VACUUM не даёт ничего? Пробовали VACCUM VERBOSE? Кроме того, обычно (в типичных ситуациях) запукать VACUUM вручную вообще не нужно, нужно настраивать autovacuum.

ну естественно, у Andrey есть приход от вакуума)) какое-то время база не растет дальше)

То есть, обычный VACUUM не даёт ничего? Пробовали VACCUM VERBOSE? Кроме того, обычно (в типичных ситуациях) запукать VACUUM вручную вообще не нужно, нужно настраивать autovacuum.

Автовакуум тоже не спасает. Допустим есть приложение, которое пишет в постгрес. Потом удаляет данные. Вижу автовакуум в процессах. А место не высвобождается.

Спасибо за ссылки раскурю в вакууме ?

но на живой базе это скорее исключение, особенно если это OLTP c интенсивным построчными DML

Но это в зависимости от шаблона удаления/изменения строк. Допустим, если мы реализуем очередь и consumer активнее producer'а так что очередь большую часть времени пуста, truncate будет происходить постоянно

))))

Автовакуум тоже не спасает. Допустим есть приложение, которое пишет в постгрес. Потом удаляет данные. Вижу автовакуум в процессах. А место не высвобождается.

мониторить это можно через расширение pgstattuple

тно я уверен, что процент таких решений ничтожно мал по отношению к базам, которые юзаются обычными орм-ками

А чем опасен vacuum full ?

где в таблице юзеров лежит поле “ласт_логин” или еще какая ерунда

которую непременно нужно долбить 1000 раз в секунду

как единоразовое решение - может быть

НО нужно иметь двойной запас места на диске)

Автовакуум тоже не спасает. Допустим есть приложение, которое пишет в постгрес. Потом удаляет данные. Вижу автовакуум в процессах. А место не высвобождается.

Сейчас заглянул в код vacuum.c, cluster.c: 1. VACUUM FULL записывает кортежи по порядку, без промежутков - это должно уменьшать размер отношения, если возможно. Для индексов делает REINDEX - также размер падает. 2. VACUUM удаляет dead-кортежи, не изменяя положения живых, т.е. все блоки остаются на месте. Единственный случай, когда обычный VACUUM уменьшает размер, как я понимаю, это когда в конце отношения имеются пустые блоки, выполняется TRUNCATE.

> VACUUM удаляет dead-кортежи, не изменяя положения живых, т.е. все блоки остаются на месте. Не, ну живые он скорее будет дефрагментировать в рамках страницы

> VACUUM удаляет dead-кортежи, не изменяя положения живых, т.е. все блоки остаются на месте. Не, ну живые он скорее будет дефрагментировать в рамках страницы

совершенно верно, но само количество страниц остается неизменным.

я бы Вам посоветовал действовать следующим образом 1. сохранить список всех таблиц с их полным размером (данные + индексы) 2. бэкап-рестор 3. сравнение реза из пункта 1 с результатом после рестора (что поможет опеределить, база равномерно блоатится, или есть определенные лидеры по мусору) 4. настройка автовакуума исходя из п.3

> VACUUM удаляет dead-кортежи, не изменяя положения живых, т.е. все блоки остаются на месте. Не, ну живые он скорее будет дефрагментировать в рамках страницы

нет

нет

в исходники смотрели?

Народ, почему может не работать репликация? Ошибок в логах нет, но репликации тоже

Ребята срочняк! Надо нечто чем можно перенести, конвертировать из mssql в postgresql

Народ, почему может не работать репликация? Ошибок в логах нет, но репликации тоже

запущенные экземпляры ничего о репликации не знают? Проверьте соответствующие настройки, подключившись к консоли, либо show <variable>, либо select * from pg_settings where name='<need variable>'

Ребята срочняк! Надо нечто чем можно перенести, конвертировать из mssql в postgresql

вроде есть mssql2pg на подобии ora2pg

вроде есть mssql2pg на подобии ora2pg

Грациас

вроде есть mssql2pg на подобии ora2pg

Гугл плачет. Ссылочкой не подсобишь?

в исходники смотрели?

сейчас - нет, но лет 5 назад, когда подсел на PG, сидел с документацией и исходниками, пытаясь понять, что за такое этот вакуум

Гугл плачет. Ссылочкой не подсобишь?

сча поисчу

сейчас - нет, но лет 5 назад, когда подсел на PG, сидел с документацией и исходниками, пытаясь понять, что за такое этот вакуум

Это интересно, надо самому глянуть

я наизусто только http://ora2pg.darold.net/ помню)

Это интересно, надо самому глянуть

уже скачал 11 Бета 3, буду перед сном читать)

А чем опасен vacuum full ?

. Он всё сжимает максимально, что может быть далеко от "рабочего" режима базы. . После него, по-хорошему, нужно делать обычный VACUUM.

. Он всё сжимает максимально, что может быть далеко от "рабочего" режима базы. . После него, по-хорошему, нужно делать обычный VACUUM.

А вот это непонятно

обычный вакуум никак не изменит состояние бд после vacuum full

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

обычный вакуум никак не изменит состояние бд после vacuum full

Ошибаетесь. ;) VACUUM FULL "сносит" visibility map (да, глупо, но факт) — про index-only scan можно забыть. :(

А чем опасен vacuum full ?

ну и ещё он требует 2x места. Если у вас есть терабайтная табличка и вы делаете vacuum full, то нужно 2 терабайта на диске.

Ошибаетесь. ;) VACUUM FULL "сносит" visibility map (да, глупо, но факт) — про index-only scan можно забыть. :(

Интересно, уточню.

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

order by random() не очень как-то, по кругу 10 записей отдает из 1000

ну то есть очень много повторений

в mysql советуют SELECT f.id FROM files f JOIN ( SELECT RAND() * (SELECT MAX(id) FROM files) AS max_id ) AS m WHERE f.id >= m.max_id ORDER BY f.id ASC LIMIT 1; только там RAND() — значение между 0 и 1 не знаю как это в постгресе, не пробовал еще

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

последние N цифр таймстампа используй хД

в mysql советуют SELECT f.id FROM files f JOIN ( SELECT RAND() * (SELECT MAX(id) FROM files) AS max_id ) AS m WHERE f.id >= m.max_id ORDER BY f.id ASC LIMIT 1; только там RAND() — значение между 0 и 1 не знаю как это в постгресе, не пробовал еще

ну это будет работать только в случае, когда есть все записи, то есть в случае когда id 1 и 10000000 - почти во всех случаях будет только последняя запись

Ошибаетесь. ;) VACUUM FULL "сносит" visibility map (да, глупо, но факт) — про index-only scan можно забыть. :(

Не нашел места в коде, где удаляется visibilitymap, можешь показать?

vacuum full оставляет собственно только видимые таплы, поэтому index only scan после него очень даже будет работать.

всем привет, может кто подскажет manual что бы написать агргегирующую функцию на Си?

@AlexFedorov будет жить. Поприветствуем!

Не нашел места в коде, где удаляется visibilitymap, можешь показать?

А я не нашёл, чтобы создавалась...

vacuum full оставляет собственно только видимые таплы, поэтому index only scan после него очень даже будет работать.

Repro можете показать?

postgres=# explain select count(*) from t where x between 100 and 1000; QUERY PLAN —---------------------------------------------------------------------------— Aggregate (cost=39.09..39.10 rows=1 width=8) -> Index Only Scan using t_x_idx on t (cost=0.42..36.91 rows=874 width=0) Index Cond: ((x >= 100) AND (x <= 1000)) (3 rows) postgres=# vacuum full t; VACUUM postgres=# explain select count(*) from t where x between 100 and 1000; QUERY PLAN —---------------------------------------------------------------------------— Aggregate (cost=39.09..39.10 rows=1 width=8) -> Index Only Scan using t_x_idx on t (cost=0.42..36.91 rows=874 width=0) Index Cond: ((x >= 100) AND (x <= 1000)) (3 rows)

postgres=# explain select count(*) from t where x between 100 and 1000; QUERY PLAN —---------------------------------------------------------------------------— Aggregate (cost=39.09..39.10 rows=1 width=8) -> Index Only Scan using t_x_idx on t (cost=0.42..36.91 rows=874 width=0) Index Cond: ((x >= 100) AND (x <= 1000)) (3 rows) postgres=# vacuum full t; VACUUM postgres=# explain select count(*) from t where x between 100 and 1000; QUERY PLAN —---------------------------------------------------------------------------— Aggregate (cost=39.09..39.10 rows=1 width=8) -> Index Only Scan using t_x_idx on t (cost=0.42..36.91 rows=874 width=0) Index Cond: ((x >= 100) AND (x <= 1000)) (3 rows)

И что это демонстрирует? ;) Смотрите: CREATE TABLE t AS SELECT n FROM generate_series(1, 10000) AS g(n); CREATE UNIQUE INDEX ON t(n); VACUUM ANALYZE t; EXPLAIN ANALYZE select count(*) from t where n between 100 and 1000; Aggregate (cost=32.53..32.54 rows=1 width=8) (actual time=0.571..0.571 rows=1 loops=1) -> Index Only Scan using t_n_idx on t (cost=0.29..30.29 rows=900 width=0) (actual time=0.053..0.433 rows=901 loops=1) Index Cond: ((n >= 100) AND (n <= 1000)) Heap Fetches: 0 VACUUM FULL t; Explain ANALYZE select count(*) from t where n between 100 and 1000; — Aggregate (cost=40.53..40.54 rows=1 width=8) (actual time=1.073..1.073 rows=1 loops=1) -> Index Only Scan using t_n_idx on t (cost=0.29..38.28 rows=900 width=0) (actual time=0.155..0.950 rows=901 loops=1) Index Cond: ((n >= 100) AND (n <= 1000)) Heap Fetches: 901 См. Heap Fetches.

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

Посмотрите tablesample.

Johnson будет жить. Поприветствуем!

Hi all, I am postgesql DBA in India.

Посмотрите tablesample.

условие режет приличное количество записей из таблицы... но попробую, спасибо

условие режет приличное количество записей из таблицы... но попробую, спасибо

Подождите, какое условие? Я думал, Вам нужна просто любая... Вообще, посмотрите вот тут: https://blog.2ndquadrant.com/tablesample-and-other-methods-for-getting-random-tuples/

И что это демонстрирует? ;) Смотрите: CREATE TABLE t AS SELECT n FROM generate_series(1, 10000) AS g(n); CREATE UNIQUE INDEX ON t(n); VACUUM ANALYZE t; EXPLAIN ANALYZE select count(*) from t where n between 100 and 1000; Aggregate (cost=32.53..32.54 rows=1 width=8) (actual time=0.571..0.571 rows=1 loops=1) -> Index Only Scan using t_n_idx on t (cost=0.29..30.29 rows=900 width=0) (actual time=0.053..0.433 rows=901 loops=1) Index Cond: ((n >= 100) AND (n <= 1000)) Heap Fetches: 0 VACUUM FULL t; Explain ANALYZE select count(*) from t where n between 100 and 1000; — Aggregate (cost=40.53..40.54 rows=1 width=8) (actual time=1.073..1.073 rows=1 loops=1) -> Index Only Scan using t_n_idx on t (cost=0.29..38.28 rows=900 width=0) (actual time=0.155..0.950 rows=901 loops=1) Index Cond: ((n >= 100) AND (n <= 1000)) Heap Fetches: 901 См. Heap Fetches.

Да я был не прав.

vacuum таплы не морозит. Надо vacuum freeze явно сделать

уважаемые коллеги, подскажите может кто чего ситуация такая есть сервер postgres (9.5), master->slave хранилище azure blob storage хочется делать живой WAL backup а для того, чтобы делать WAL, нужно сделать base/snapshot сначала, то есть начальное состояние базы вроде бы нашлось решение под названием wal-e но оно стартует backup так "SELECT file_name, " " lpad(file_offset::text, 8, '0') AS file_offset " "FROM pg_{0}file_name_offset(" " pg_start_backup('{1}'))" это можно делать только на мастере, на слейве происходит ERROR: recovery is in progress HINT: WAL control functions cannot be executed during recovery. хочется понять, есть ли какие-то варианты кроме того чтобы допиливать wal-e самому (чтобы вызывать pg_basebackup, который будет делать снапшот с мастера) может быть, есть какие-то иные работающие решения для postgresql WAL -> Azure ? спасибо за внимание

backup с мастера технически возможный вариант, но клиент не хочет нагрузки на мастер лишней

"клиент" в смысле "заказчик"

уважаемые коллеги, подскажите может кто чего ситуация такая есть сервер postgres (9.5), master->slave хранилище azure blob storage хочется делать живой WAL backup а для того, чтобы делать WAL, нужно сделать base/snapshot сначала, то есть начальное состояние базы вроде бы нашлось решение под названием wal-e но оно стартует backup так "SELECT file_name, " " lpad(file_offset::text, 8, '0') AS file_offset " "FROM pg_{0}file_name_offset(" " pg_start_backup('{1}'))" это можно делать только на мастере, на слейве происходит ERROR: recovery is in progress HINT: WAL control functions cannot be executed during recovery. хочется понять, есть ли какие-то варианты кроме того чтобы допиливать wal-e самому (чтобы вызывать pg_basebackup, который будет делать снапшот с мастера) может быть, есть какие-то иные работающие решения для postgresql WAL -> Azure ? спасибо за внимание

Wal-g

Wal-g

там нет поддержки Azure, только AWS https://github.com/wal-g/wal-g/issues/9

к тому же в Azure там недавно поменялся blob API, к wal-e был патч пару месяцев назад

можно попробовать из wal-g в wal-e портировать конечно, если найти время и вдохновение )

можно попробовать из wal-g в wal-e портировать конечно, если найти время и вдохновение )

Лучше wal-g допилить

azure api ужасный, но я как раз Go хотел поизучать

а о wal-g есть позитивное мнение?