AA
vacuum для всей базы запустить не получится, потому что нужно место, сравнимое с размером базы- есть идея запускать vacuum full для одной таблицы, затем для второй и т.д.
Size: a a a
2020 June 21
AA
таким образом можно вернуть обьем в файловую систему
AA
но у Вас, как я посмотрел, даже vacuum для одной таблицы не сработает- места вообще нет
GS
К сожалению совсем нет возхможности докинуть место. Может быть из другого раздела позаимствовать думаю
главное ни в коем случае не используйте pg_resetwal для решения вашей проблемы
mn
День добрый, сразу с вопросом (наверное как каждый второй новоприбывший), появилась нужда логировать все запросы в определенную базу(можно все ибо база всего одна). После гуглений удается логировать запросы из клиента psql, но запросы через pdo не логируются, может кто-то подскажет где покрутить?
GS
День добрый, сразу с вопросом (наверное как каждый второй новоприбывший), появилась нужда логировать все запросы в определенную базу(можно все ибо база всего одна). После гуглений удается логировать запросы из клиента psql, но запросы через pdo не логируются, может кто-то подскажет где покрутить?
mn
спасибо, досвидания
DP
кстати, про логи - есть боль с тем, что кажется недовыполнившиеся запросы в логи не попадают, что неудобно - залипший на час запрос в логах будет только через час. это как-то чинится, кроме поллинга pg_stat_activity?
GS
кстати, про логи - есть боль с тем, что кажется недовыполнившиеся запросы в логи не попадают, что неудобно - залипший на час запрос в логах будет только через час. это как-то чинится, кроме поллинга pg_stat_activity?
нет, попадают
GS
но это не точно =)
сейчас проверю
сейчас проверю
DP
может быть попадают, но интересен автоэксплейн :))
GS
да, просто стейтменты попадают в лог до выполнения, параметр log_statements
VG
Как бороться с планировщиком правильно? Есть запрос до 10 join-ов и anti-join-ов, планировщик похоже решил, что выгоднее сделать сначала anti-join, после них на выходе будет мало строк, а остальное indexscan-ом в цикле - в этом месте операция повторяется 50к тысяч раз и съедает 90+% времени. Если отключить enable_indexscan и enable_bitmapscan, запрос ускоряется в ~100 раз.
https://explain.depesz.com/s/5aau
https://explain.depesz.com/s/5aau
VG
легко оптимизировать с помощью cte, но возможно есть более правильный способ
🕵
Alex Alex
но у Вас, как я посмотрел, даже vacuum для одной таблицы не сработает- места вообще нет
У меня получилось миграцию запустить данных в другую базу. Надеюсь перекинуть часть данных и грохнуть таблицы для освобождения памяти. Но кардинально это вопрос не решит, скорее всего
DP
Как бороться с планировщиком правильно? Есть запрос до 10 join-ов и anti-join-ов, планировщик похоже решил, что выгоднее сделать сначала anti-join, после них на выходе будет мало строк, а остальное indexscan-ом в цикле - в этом месте операция повторяется 50к тысяч раз и съедает 90+% времени. Если отключить enable_indexscan и enable_bitmapscan, запрос ускоряется в ~100 раз.
https://explain.depesz.com/s/5aau
https://explain.depesz.com/s/5aau
когда я вижу где-то что-то про битмап, у меня инстинкт проверить random_page_cost и work_mem
VG
random_page_cost = 1.1 - вроде частая рекомендация для ssd (проверил на дефолтных 4 - не помогло). А про work_mem не понял, как это влияет - можно мысль немного развернуть?
VG
bitmap scan вылазит, когда indexscan отключаю
M
кстати, про логи - есть боль с тем, что кажется недовыполнившиеся запросы в логи не попадают, что неудобно - залипший на час запрос в логах будет только через час. это как-то чинится, кроме поллинга pg_stat_activity?
да, есть такая штука( тоже самое с автоэксплейном, план не получим до завершения запроса.