Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
От | James Inform |
---|---|
Тема | Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 |
Дата | |
Msg-id | 9586ada6-344e-ff26-8c16-6c847a984220@pharmapp.de обсуждение исходный текст |
Ответ на | Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-bugs |
That's strange. I see those copy commands it pg_stat_statments and they have 1 calls. The backup job runs once a day since many months. I would expect to see calls > 1 then. So again very strange, but maybe a layer 8 problem :) I will recheck. Julien Rouhaud Wrote: > On Mon, Aug 16, 2021 at 4:46 PM PG Bug reporting form > <noreply@postgresql.org> wrote: >> The following bug has been logged on the website: >> >> I have just updated to 13.4 and I have noticed that "COPY" statements that >> are produced by pg_dump appear in pg_stat_statements view. >> >> You can imagine that the copy statements are slower than all my other >> statements, so they come up as the first and most expensive statements in >> pg_stat_statements. > You could order by the average execution time rather than the total > execution time and/or filter out queries executed less than X times, > it's more likely to give you low hanging fruits. > >> This is a new behaviour in 13.4 and hasn't existed in 13.3 and prior. > Nothing changed here for a long time. > >> Is there a setting to prevent this? > You could disable pg_stat_statements.track_utility, but it obviously > means that all utility statements will be ignored, not only COPY.
В списке pgsql-bugs по дате отправления: