From: | Nandakumar M <m(dot)nanda92(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org, guillaume(dot)poussel(at)sogeti(dot)com |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | RE: Query is slow when run for first time; subsequent execution is fast |
Date: | 2018-01-17 10:09:36 |
Message-ID: | CANcFUu52cPxGgr=mPpbgq5vQRv-VuadSSDpdf=PCbTnr2ndQ8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On 17 Jan 2018 12:55, "POUSSEL, Guillaume" <guillaume(dot)poussel(at)sogeti(dot)com>
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 entry in my db startup script to run this query
immediately after startng the server, and let the query warm the cache
itself.
I will try this suggestion and get back on the thread. Is pg_statistic the
only table to be pre cached? Pls let me know if any other table/index needs
to be pre warmed.
Btw, I don't running a "select * from pg_statistic" will fill the shared
buffer. Only 256 kb of data will be cached during sequential scans. I will
try pg_prewarm
Why do you restart your database often
Postgres is bundled with our application and deployed by our client.
Starting / stopping the server is not under my control.
Regards,
Nanda
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-01-18 01:55:32 | Re: Query is slow when run for first time; subsequent execution is fast |
Previous Message | POUSSEL, Guillaume | 2018-01-17 07:25:10 | RE: Query is slow when run for first time; subsequent execution is fast |