From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Arjen van der Meijden <acm(at)tweakers(dot)net> |
Cc: | "'scott(dot)marlowe'" <scott(dot)marlowe(at)ihs(dot)com>, "'Ernest E Vogelsinger'" <ernest(at)vogelsinger(dot)at>, "'Justin Clift'" <justin(at)postgresql(dot)org>, "'Joseph Shraibman'" <jks(at)selectacast(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres performance comments from a MySQL user |
Date: | 2003-06-16 23:35:26 |
Message-ID: | 7704.1055806526@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Arjen van der Meijden <acm(at)tweakers(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ernest E Vogelsinger | 2003-06-16 23:38:52 | Re: Postgres performance comments from a MySQL user |
Previous Message | Sven Köhler | 2003-06-16 23:22:37 | Re: RE : full featured alter table? |