и я об этом писал тут вроде

а ты где слышал про это?

в общем релейшны в 2 раза больше исходных почему-то

помогает только вакуум фул

Слышал от еще знакомого разработчика и здесь видел сообщения об этом

Только репак?

не понял про репак

обычный вакуум я так понимаю не лечит?

не лечит

только фул

pg_repack я имел в виду. Чтобы не блокировать

ты это "репаком" называешь?

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

а про pg_repack чет не слышал

ща гляну

а, тогда да, можно и фул запустить

Спасибо за инфу

http://reorg.github.io/pg_repack/

а что там внутри то происходит, что за магия, и почему ее нет в коробке тогда?

почему тот же фул не сделать аналогично?

должен же быть подвох в чем-то?

быстро пробежал man пока не понял

понял, там прямые операции с каталогом делаются

Суть расширения в том, что он создает копию таблицы, навешивает на родительскую таблицу триггер, чтобы не потерять данные. Затем удаляет триггер, удаляет старую таблицу и запускает анализ. Можно пересобрать например только индексы. Или один из индексов.

У расширения есть конечно ряд ограничений, но в 90% случаев это очень помогает обслужить БД без простоя.

вы правы, работа идет с каталогом

Кто нибудь пробовал использовать pg_logical в связке с потоковой репликацией? Например, есть n мастеров, у которых часть таблиц реплицируется с одного на другой, а у каждого мастера есть набор слейвов с потоковой репликацией. По идее, если установить уровень WA-логов logical то hot_standby более низкий уровень записи логов и потоковая репликация должна работать нормально.

Работает. Только увеличивается объем генерируемых логов

Это само собой)

logical добавляет информацию, требуемую для поддержки логического декодирования

коллеги, кто-нить быстрый рецепт как найти блокирвки на таблицы подскажет?

SELECT blocked_locks.pid AS blocked_pid, blocked_activity.usename AS blocked_user, blocking_locks.pid AS blocking_pid, blocking_activity.usename AS blocking_user, blocked_activity.query AS blocked_statement, blocking_activity.query AS blocking_statement FROM pg_catalog.pg_locks blocked_locks JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid AND blocking_locks.pid != blocked_locks.pid JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid WHERE NOT blocked_locks.GRANTED

один из вариантов

мне помог такой: SELECT relation::regclass, * FROM pg_locks WHERE NOT GRANTED;

вополне наглядно и не так страшно :)

но идею понял

wiki нашел

Всем привет

Возник вопрос по ON CONFLICT ... DO UPDATE SET, каким способом можно узнать какое действие произошло (INSERT или UPDATE) по примеру EXPLAIN ANALYZE EXPLAIN ANALYZE INSERT INTO test2(tt, cnt) VALUES('asd1', 1) ON CONFLICT (tt) DO UPDATE SET cnt = test2.cnt + 1; QUERY PLAN —------------------------------------------------------------------------------------------- Insert on test2 (cost=0.00..0.01 rows=1 width=0) (actual time=0.074..0.074 rows=0 loops=1) Conflict Resolution: UPDATE Conflict Arbiter Indexes: t2_tt Tuples Inserted: 0 Conflicting Tuples: 1 -> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1) Planning time: 0.044 ms Execution time: 0.116 ms (8 rows) test=# EXPLAIN ANALYZE INSERT INTO test2(tt, cnt) VALUES('asd2', 1) ON CONFLICT (tt) DO UPDATE SET cnt = test2.cnt + 1; QUERY PLAN —------------------------------------------------------------------------------------------- Insert on test2 (cost=0.00..0.01 rows=1 width=0) (actual time=0.057..0.057 rows=0 loops=1) Conflict Resolution: UPDATE Conflict Arbiter Indexes: t2_tt Tuples Inserted: 1 Conflicting Tuples: 0 -> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.001..0.002 rows=1 loops=1) Planning time: 0.034 ms Execution time: 0.093 ms

В репаке есть прикол, если у тебя большое количество транзакций, очень большое, то репак может все перелочить

И все зависнет

А так все работает

т.е. для биллинга не вариант?

Вариант

Но смотря сколько транзакций, и какое железо

https://ayende.com/blog/175137/re-why-uber-engineering-switched-from-postgres-to-mysql

У меня на 25 к транзакций в минуту репак вставал в тупик,

Иногда вечный тупик

В 6 потоков, около 800 таблиц

https://ayende.com/blog/175137/re-why-uber-engineering-switched-from-postgres-to-mysql

да уже смотрели

кто-то бил себя пяткой в грудь и кричал что уберовцы неосилянты

Ну наверное у людей были свои аргументы

но я так не считаю

Ну ладно

Я так понял, что ребятам просто нравится мигрировать с одной БД на другую раз в 3 года. До этого они мигрировали с mysql на postgresql в 2013 году и делали об этом доклад

Видимо есть обратная сторона медали, такая как бюджет

На сервера и каналы

Типа денег нет а надо

Ну раз надо то вперёд,

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

У меня осталось впечатление, что многие аргументы притянуты за уши. Особенно по репликации.

Ну уперлись в дисковую стойку похоже

Тогда это похоже на правду

Ибо все что сказано выглядит как дефицит io

да... с репликацией в MySQL я хлебнул в своое время

но им нужна походу логическая репликация

которая ща появилась и в pg

Мы незнаем всей ситуации

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

ууу

ну это жесткий был вариант

там и так сетуют что на каждый апдейт делается несколько логических IO (по кол-ву доп. индексов)

так еще и доп. IO на то, чтоб сохранить в сторнней табличке (кооторая имеет свои индексы), потом удалить

на больших нагрузках это уже фатально

хотяб в плане стоимости железа

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

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

конечно есть

Лондист кака

А кто пользуется постгресом в RDS?

Как бы там сделать логгирование всех запросов, которые дольше Х?

Кажется нашел.

Странная тема. Применил Parameters Group с настройками по примеру как здесь: http://www.getfareye.com/in/blog/amazon-rds-postgres-activate-slow-query-logs Запустил ну определенно долгий запрос и чет в логах его нет. RDS ребутал после применения группы тоже.

Всем привет! Можете дать консультацию? Создаю функцию CREATE FUNCTION, в которой есть несколько "независимых" блоков: 1. вызов функции логиновария 2. проверка входных параметров 3. INSERT 4. UPDATE 5 возврат результата Каждый блок обёрнут в BEGIN-EXCEPTION-END. Если возникает где то ошибка - то откатывается всё внутри данной функции. Такое поведение мне не приемлимо. Нужно, чтобы всё, что было сделано в базе до оператора, вызвавшего EXCEPTION сохранялось. Как это можно реализовать? Единицей работы базы является вызов функции. Т.е. клиент просто вызывает нужные функции.

знаю что для логирования и спользуют костыль с db-link-ом

и вроде как штатных средств сделать автономные транзакции нет

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

Спасибо за ответ

Тогда попробую зайти с другого бока

есть таблицы: tbl1, tbl2, tbl3

мне нужно при вставке в tbl1 вызывать функцию fnc12, которая вставляет данные в tbl2, потом при появлении записи в tbl2 вызвать функцию в fnc23, которая вставляет в tbl3.

реализовал на ториггерах AFTER INSERT

но оно не работает как надо! данные не консистентны

а что значит "не консистентны"?

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