Hi,
I tried pg_prewarm as suggested by Jeff Janes and it works - thanks a lot
Jeff. Now the query planning is fast on the first execution.
Here is the list of tables that needed to be pre warmed (or you could just
pre warm all the 'pg_%' tables. :-) ).
select pg_prewarm('pg_statistic');
select p
On Jan 26, 2018 3:00 AM, "Alvaro Herrera" wrote:
pavan95 wrote:
> Hi Álvaro Herrera,
>
> Please find the corresponding output:
OK, these settings look pretty normal, so they don't explain your
problem.
What is checkpoint_segments set to? And checkpoint_timeout?
--
Álvaro Herrera
On 01/24/2018 12:48 PM, Stefan Petrea wrote:
> Hello,
>
> This email is structured in sections as follows:
>
> 1 - Estimating the size of pg_xlog depending on postgresql.conf parameters
> 2 - Cleaning up pg_xlog using a watchdog script
> 3 - Mailing list survey of related bugs
> 4 - Thoughts
>
pavan95 wrote:
> Hi Álvaro Herrera,
>
> Please find the corresponding output:
OK, these settings look pretty normal, so they don't explain your
problem.
What is checkpoint_segments set to? And checkpoint_timeout?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Develop
Stefan Petrea wrote:
> During some database imports(using pg_restore), we're noticing fast
> and unbounded growth of pg_xlog up to the point where the
> partition(280G in size for us) that stores it fills up and PostgreSQL
> shuts down.
What do you see in pg_stat_archiver?
Yours,
Laurenz Albe
