From: Josh Berkus <josh@agliodbs.com>
To: Chris Faulkner <chrisf@oramap.com>
To: Pgsql-Performance <pgsql-performance@postgresql.org>
Subject: Re: [SQL] sql performance and cache
Date: Sun, 12 Oct 2003 14:31:19 -0700
Message-ID: <200310121431.19796.josh@agliodbs.com> (raw)
In-Reply-To: <DGENKIKMJILAAKJGFHKFKEKGCIAA.chrisf@oramap.com>
References: <DGENKIKMJILAAKJGFHKFKEKGCIAA.chrisf@oramap.com>
Chris, People:
(Dropped SQL list because we're cross-posting unnecessarily)
> I am not sure I agree with you. I have done similar things with Oracle and
> found that the second query will execute much more quickly than the first.
> It could be made to work in at least two scenarios
Actually, PostgreSQL often DOES cache data, it just uses the Kernel cache
rather than any memory application built into Postgres, and it caches the
underlying data, not the final query results. Base data for query sets gets
cached in RAM after a query, and the second query often *does* run much
faster.
For example, I was running some queries against the TPC-R OSDL database, and
the first time I ran the queries they took about 11 seconds each, the second
time (for each query) it was about 0.5 seconds because the data hadn't
changed and the underlying rowsets were in memory.
I think it's likely that your machine has *already* cached the data in memory,
which is why you don't see improvement on the second run. The slow execution
time is the result of bad planner decisions and others are helping you adjust
that.
Now, regarding caching final query results in memory: This seems like a lot of
effort for very little return to me. Doing so would require that all
underlying data stay the same, and on a complex query would require an
immense infrastructure of data-change tracking to verify.
If you want a data snapshot, ignoring the possibility of changes, there are
already ways to do this:
a) use a temp table;
b) use your middleware to cache the query results
Now, if someone were to present us with an implementation which effectively
built and automated form of option (b) above into a optional PG plug-in, I
wouldn't vote against it. But I couldn't see voting for putting it on the
TODO list, either.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: josh@agliodbs.com, chrisf@oramap.com, pgsql-performance@postgresql.org
Subject: Re: [SQL] sql performance and cache
In-Reply-To: <200310121431.19796.josh@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox