Ролг ХупинЕще лучше, если можно отловить запросы от юзера, которые выполняются долго, скажем, в нормальной жизни - 2-3 сек, а в этом случае 10-15
Где и какие настройки изменить?

Зы. пробовал pgAdmin4 в его Dashboard что-то смотреть - фигня какая-то...


включить лог длинных запросов... можно для конкретного пользователя
(log_min_duration_statement)

Ролг ХупинMaxim Bogukпропущено...



включить лог длинных запросов... можно для конкретного пользователя
(log_min_duration_statement)

спасибо! отловил.

Возникли вопросы:
1. Вижу, что длинный вызов select * from fun(...)
Explain его не объясняет, точнее не объясняет запросы, которые внутри. Нельзя вызов функции объяснить explain, чтобы с подробностями?

2. Нашел внутри функции один из запросов, который практически и дает длинное выполнение.
Сделал explain and analyze, где можно почитать как анализировать план, на что обратить внимание?

3. Умеет ли сервер писать логи не в файл, а в таблицу в базе?

1 - нет нельзя но я смотрю вы уже сами раскопали проблемный запрос

2 - ну или написать его сюда вместе с планом и вам скорее всего подскажут что и почему и как или обратится в коммерческую поддержку postgresql

3 - нет не умеет (тем более что лог может писаться когда база уже помирает и в нее ничего записать не возможно например, или включен лог вообще всех запросов (а дальше при попытке писать его в базу начинается рекурсия).


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Ролг ХупинПишет
"Planning time: 7.747 ms"
"Execution time: 19493.261 ms"

Куда смотреть? Куда бежать?

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

вариантов куча... но вот по "Execution time: 19493.261 ms" вам никто ничего не скажет не видя запроса и плана.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Ролг ХупинMaxim Bogukпропущено...


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

вариантов куча... но вот по "Execution time: 19493.261 ms" вам никто ничего не скажет не видя запроса и плана.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Кстати, у меня случай, как в книжке описан:

авторcar_portal=> EXPLAIN SELECT search_key FROM account_history WHERE account_id = 2000 GROUP BY QUERY PLAN
------------------------------------------------------------------------------------
Limit (cost=27.10..27.13 rows=10 width=23)
-> Sort (cost=27.10..28.27 rows=468 width=23)
Sort Key: (max(search_date))
-> HashAggregate (cost=12.31..16.99 rows=468 width=23)
Group Key: search_key
-> Seq Scan on account_history (cost=0.00..9.95 rows=472 width=23)
Filter: (account_id = 2000)
(7 rows)

Again, the index is not used, because we would like to read the whole table. Index
selectivity here is very low since account 2000 has 427 records, where account 1000
only has four records, as shown below:

car_portal=> SELECT count(*), account_id FROM account_history group by account_id;
count | account_id
-------+------------
472 | 2000
4 | 1000
(2 rows)

Finally, let's rerun the query again for account 1000. In this case, the selectivity is
high, thus the index will be used:



Т.е. "the index is not used, because we would like to read the whole table. Index
selectivity here is very low"


И как быть в таком случае при низкой селективности индекса? построить другой индекс?

Если надо выбрать больше чем 10-30% от таблицы это всегда быстрее сделать через seq scan.
Index scan никак не помогает от того что вам надо миллион строк обработать.
Если же есть какие то еще условия в запросе - да более селективный индекс может помочь.