Arjen van der Meijden <acm@tweakers.net> writes:
> Well, then there is not. It would still be nice, however, to know why
> queries are faster the second time they're run, even if there is a 100%
> cachehit for the first running query.
Well, there are non-plan caches involved --- specifically the catalog
cache and relation cache. The first query issued against a given table
in a session will incur the cost to load the cache entries needed, and
the first few queries in a session incur quite a few cache loads to suck
in basic information like pg_operator and pg_proc entries for common
functions and operators.
For example, on my machine with the regression database, the time for
explain select * from tenk1 where unique1 = 42;
drops from ~18ms first time to ~5ms subsequent times. AFAICS the only
thing that could cause that difference is catcache/relcache loading.
regards, tom lane
