How disable postgresql “Cache” optimization?

Question

I\'m trying to optimize my function.
The thing is when you run the query once you get one result.
Run the query a second time or third time the process time is muc

Answer 1

Since you said you want to optimize your function, not your disk layout, then the 2nd timings are probably the ones you want to focus on for that purpose, as they are the purest measure of the run time of your function itself, rather than the time needed to gather the data to feed into your function.

And since the 2nd-execution time is still 2/3 of the 1st execution time, that would still be where to focus your attention even if what you want to optimize total execution time.

If you really need to do this, you can clear the cache as explained in another answers, but that is usually too onerous to be used for routine work. Better would be to create a program/script that picks random (but generally realistic) values of a.X, a.Y, a.azimuth and runs the query with them. By changing the values each time from among a set of realistics examples, you get results most representative of the real world. Making such drivers is a little more work upfront but usually pays off.

Answer 2

sync; sudo service postgresql stop; echo 1 > /proc/sys/vm/drop_caches; sudo service postgresql start

Answer 3

PostgreSQL doesn't have a "cache" optimisation, in the sense of a query result cache.

It does cache table blocks that were recently read in shared_buffers, but for most installs that only has a small effect. The main cache is the operating system's disk read cache. For more information see:

See and clear Postgres caches/buffers?

It sounds to me like you have a system with a reasonable amount of RAM and a fast CPU but a terribly slow disk. So queries that only hit the OS's disk cache are very fast, but queries that go to disk take a couple of seconds to read the data in. So caching effects are very strong.

You should explain (buffers, analyze, verbose) SELECT ... your queries. Try with a couple of different input values until you get a slow one. Compare plans.

If the plans are the same, that's probably it.

If the plans are different, you're probably hitting a situation where the query planner is making bad choices based on variations in the table statistics. Increasing the statistics targets for the columns of interest may help (see the manual). If you get different plans and are stuck / want help, feel free to post a new question on dba.stackexchange.com with details.