| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Nandakumar M <m(dot)nanda92(at)gmail(dot)com>, "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Query is slow when run for first time; subsequent execution is fast |
| Date: | 2018-01-18 01:55:32 |
| Message-ID: | 20180118015532.GE29962@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
> probably just put an entry in my db startup script to run this query
> immediately after startng the server, and let the query warm the cache
> itself.
>
> Why do you restart your database often enough for this to be an issue?
Another thing that you could use here is pg_buffercache which offers a
way to look at the Postgres shared buffer contents in real-time:
https://www.postgresql.org/docs/current/static/pgbuffercache.html
As Jeff says, pg_prewarm is a good tool for such cases to avoid any kind
of warmup period when a server starts..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Svensson Peter | 2018-01-18 12:12:26 | pgaudit and create postgis extension logs a lot inserts |
| Previous Message | Nandakumar M | 2018-01-17 10:09:36 | RE: Query is slow when run for first time; subsequent execution is fast |