Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 - Mailing list pgsql-bugs

From Julien Rouhaud
Subject Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
Date
Msg-id CAOBaU_YFnWjqpkw7jQCB2J-FQNyPbFj_YQRpsuj6Z16Na+5A_g@mail.gmail.com
Whole thread Raw
In response to BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4  (PG Bug reporting form <noreply@postgresql.org>)
List 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 by date:

Previous
From: James Inform
Date:
Subject: Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
Next
From: James Inform
Date:
Subject: Re: BUG #17145: Invalid memory alloc request size, when searching in text column with big content > 250MB