Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
От | Julien Rouhaud |
---|---|
Тема | Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 |
Дата | |
Msg-id | CAOBaU_YFnWjqpkw7jQCB2J-FQNyPbFj_YQRpsuj6Z16Na+5A_g@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
On Mon, Aug 16, 2021 at 5:48 PM James Inform <james.inform@pharmapp.de> wrote: > > 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. One possibility is that pg_stat_statements.max is too small, leading to pg_stat_statements evicting the least frequently used entries. You can compare the current number of entries to the pg_stat_statements.max and see if it has between 95 and 100% of entries allocated. Note that pg_stat_statements entry eviction is quite costly, so if that the reason why you don't see more execution you may want to increase pg_stat_statements.max. It might not be an option if you have hundred of thousands of tables though, and in that case disabling track_utility may be a better option. Another good option may also be to change you backup approach and rely on physical backup rather than pg_dump, which would solve your original problem and also probably improve your RPO.
В списке pgsql-bugs по дате отправления: