On Tue, Sep 4, 2018 at 3:16 AM jimmy wrote:
> On windows, how to put an entry in my db startup script to run this query
> （pg_prewarm） immediately after startng the server, and let the query warm
> the cache itself.
>
Starting with PostgreSQL version 11 (to be released soon), you can use
pg_pre
On windows, how to put an entry in my db startup script to run this query
（pg_prewarm） immediately after startng the server, and let the query warm the
cache itself.
After starting the server, I want to know what is the server, and it is the
database I restarted or windows system?
Thank you.
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 Tue, Jan 16, 2018 at 09:18:25PM -0800, Jeff Janes wrote:
> Oh. I've not seen that before. But then again I don't often restart my
> server and then immediately run very large queries with a stringent time
> deadline.
>
> You can try pg_prewarm, on pg_statistic table and its index. But I'd
>
Hi,
On 17 Jan 2018 12:55, "POUSSEL, Guillaume"
wrote:
Are you on Windows or Linux? I’m on Windows and wondering if the issue is
the same on Linux?
I have experienced this on Mac and Linux machines.
You can try pg_prewarm, on pg_statistic table and its index. But I'd
probably just put an entr
? I’m on Windows and wondering if the issue is the
same on Linux?
BR,
Guillaume
De : Jeff Janes [mailto:jeff.ja...@gmail.com]
Envoyé : mercredi 17 janvier 2018 06:18
À : Nandakumar M
Cc : pgsql-performa.
Objet : Re: Query is slow when run for first time; subsequent execution is fast
On Fri, Jan 12, 2018 at 12:03 AM, Nandakumar M wrote:
> Hello Jeff,
>
> Thanks for the insights.
>
> >Don't keep closing and reopening connections.
>
> Even if I close a connection and open a new one and execute the same
> query, the planning time is considerably less than the first time. Only
>
Nandakumar M schrieb am 12.01.2018 um 09:03:
> Even if I close a connection and open a new one and execute the same
> query, the planning time is considerably less than the first time.
> Only when I restart the Postgres server then I face high planning
> time again.
Yes, because the data is cached
Missed to have mailing list in to address.. forwarding now.
-- Forwarded message --
From: "Nandakumar M"
Date: 15 Jan 2018 12:16
Subject: Re: Query is slow when run for first time; subsequent execution is
fast
To: "Pavel Stehule"
Cc:
Hi,
On Fri, Jan 12, 20
2018-01-12 9:03 GMT+01:00 Nandakumar M :
> Hello Jeff,
>
> Thanks for the insights.
>
> >Don't keep closing and reopening connections.
>
> Even if I close a connection and open a new one and execute the same
> query, the planning time is considerably less than the first time. Only
> when I restart
Hello Jeff,
Thanks for the insights.
>Don't keep closing and reopening connections.
Even if I close a connection and open a new one and execute the same query,
the planning time is considerably less than the first time. Only when I
restart the Postgres server then I face high planning time again
On Wed, Jan 10, 2018 at 3:59 AM, Nandakumar M wrote:
>
> I am not using prepared statements. Postgres documentation and previous
> questions in the pgsql-performance mailing list mention that the query plan
> is cached only when prepared statements are used.
>
> https://www.postgresql.org/message
12 matches
Mail list logo
