ну это скорее следствие того хака, которым это реализовано. если это делать именно из коробки, то нужен SQL синтаксис. А если прикручивать сбоку, то можно код из крона выдрать, да

ну то такое. а ещё что-нибудь?

есть же просто и очевидные недостатки: extension с бинарными пакетами только под centos, числовые id вместо символьных имён, поминтное разрешение (унаследованное от cron кстати) и т.д. Мне вот любопытно стало, как это поделие автоматически "лучше" умудрилось стать

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

Логическая репликация в десятке будет.

да я в курсе. не о том речь

если кто-то ещё пишет большие штуки на psql, я тут завёл тикет в DataGrip про поддержку \set, его можно полайкать https://youtrack.jetbrains.com/issue/DBE-4660

Всем привет, хорошего воскресенья. Логировать баги и исключения лучше в постгрю или в файл? Как лучше с точки зрения скорости?

Может оба одинаково или в постгрис быстрее. Тогда буду в постгрес.

Если кто замерял, скажите пожалуйста.

по-моему, "одинаково" там на запись никак быть не может

логировать откуда, куда, зачем, кто это будет читать?

почему бы не kibana/elasticsearch/logstash?

Вопрос стоит только о записи - не анализе. Ну например при исключении, логгер сейчас пишет в файл событие исключения, данные понему, трейсы

Хотя с другой стороны ротация логов же потом всеравно понадобится. @Komzpa эти продукты рассмотрю.

логи, которые не анализируют, писать не нужно :)

Я понял уж глупость своего сообщения :) Не надо добивать :)

или тот же https://sentry.io

А сам чего юзаешь?

у меня оффлайновый длинный пайплайн, так что я пишу всё в текстовые файлы простым редиректом stdout/stderr. оно всё сведено в мейкфайл и запускается под нашим профайлером, который потом выдаёт граф вызовов и тайминги если что-то зафейлилось, можно просто клацнуть в итоговой svg на таргет и порассматривать, почему. выглядит как-то так: https://github.com/gojuno/make-profiler/blob/master/make.svg

а в продакшене кибана, да

Спасибо за информацию

Еще вопрос, как ускорить удалени строк. 500 из 400 000 строк на hdd удаляет более 10 минут

Есть связанные таблицы. Порядка 10

Через using по id

?

?

DELETE FROM events USING event_types WHERE events.event_type_fk = event_types.event_type.id AND relevance_level IN ( 1, 3, 5, 7) AND <ANY_ANOTHER_CONDITION_YOU_ NEED>

?

DELETE FROM films USING producers WHERE producer_id = producers.id AND producers.name = 'foo';

Еще вопрос, как ускорить удалени строк. 500 из 400 000 строк на hdd удаляет более 10 минут

А почему так медленно? Какой план у запроса?

Вот пока не могу дождаться

уже 3 минуты пашет

А зачем WITH?

в WHERE разве нельзя добавить условие?

И так и эдак висит

А сам запрос, который id-шники вытаскивает быстро работает?

там постгрес не настроен

дефолтные настройки

вангую что упирается в диск

уже 3 минуты пашет

Так а без analyse?

А сам запрос, который id-шники вытаскивает быстро работает?

Да

Так а без analyse?

Тоже долго

Сейчас шеред мемори ставлю 2гб

Потом скажу что и как

Не может explain без analyse долго работать, если в системе все в порядке

Ему же только план показать

Хе :) Вот долго думает

Возможно потому что винт hdd

Тихо, без ошибк не запускается

Попробуй меньше поставить :)

Ладно, ребят. Тут походу у меня надолго. Полтергейст какой-то. Вообще запускаться перестал. Спасибо за потраченное время

Вот это долго работает

2Gb шаред мемори

воркмем 64Мб

а там limit 500 нужен по логике?

или это какая-то попытка оптимизации?

Хотябы 500..

Не говоря уж о 7000 строк

а delete from address_house where locality_id = 1; не быстрее?

оно должно выродиться в простой seq scan

ERROR: S client not available

Индекс нужен отдельный

Там же видно что в сек скан уперлось

analyse на delete тебе удалит, а потом вернёт обратно все строчки, по идее.

в смысле, не нужно пишущим запросам без нужды analyse делать

он же их выполняет и откатывает

если ты и так дождёшься, то выполняй без analyse

Это без эксплейна

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

с этой таблицей связано много дочерних таблиц с Ondelete restrict и 2 таблицы с ondelete cascade

ага

а limit 1 быстро выполняется?

Есть связанные таблицы. Порядка 10

Я же писал

а limit 1 быстро выполняется?

? селект или делит?

делит, такой, как у тебя с limit 500

1 сек, сейчас проверю

если быстро, то можно изобретать seq 1 500 | parallel --eta 'psql -c "delete from address_house where id = (select id from address_house where locality_id = 1 for update skip locked);"'

выполни его

план, ясное дело, такой же будет

если быстро, то можно изобретать seq 1 500 | parallel --eta 'psql -c "delete from address_house where id = (select id from address_house where locality_id = 1 for update skip locked);"'

сейчас

ну, 2.3 секунды да на 500 штук - 20 минут

ну, 2.3 секунды да на 500 штук - 20 минут

Ну долго же

Это всегда со связанными таблицами так долго?

ну, у тебя написано, какие триггеры тормозят

удали вторую строчку так же

вдруг оно погрелось и будет в кешах смотреть