If this is still an issue after you check David's theory about premature
analyzing, another approach is to pre-populate and pre-analyze future
tables. Something like this:
* disable autovac on the future table
* detach the table from the main partition
* insert a few hundred thousand rows into it,
On Fri, 2025-12-19 at 14:25 +0100, Colin 't Hart wrote:
> What's the behaviour when pg_resetwal is used to change the WAL segment size?
>
> This note is worrying to me:
> --
> While pg_resetwal will set the WAL starting address beyond the latest
> existing WAL segment file, some segment size chan
What's the behaviour when pg_resetwal is used to change the WAL segment
size?
This note is worrying to me:
--
While pg_resetwal will set the WAL starting address beyond the latest
existing WAL segment file, some segment size changes can cause previous WAL
file names to be reused. It is recommended
On Fri, 2025-12-19 at 09:26 +0100, Andrew wrote:
> As an oracle dba new to Postgres, I’m used to the concept of context switches
> and latch issues
> with regards to transaction log switches. Does Postgres have a similar
> mechanism with latching
> etc when it switches to a new wal segment that i
As an oracle dba new to Postgres, I’m used to the concept of context switches
and latch issues with regards to transaction log switches. Does Postgres have a
similar mechanism with latching etc when it switches to a new wal segment that
is alleviated when increasing the size of the wal segments?
