On Wed, 2002-02-27 at 00:39, Tom Lane wrote:
> I cannot believe that caching results for literally-identical queries
> is a win, except perhaps for the most specialized (read brain dead)
According to MySQL: "The query cache is extremely useful in an
environment where (some) tables don't change very often and you have a
lot of identical queries. This is a typical situation for many web
servers that use a lot of dynamic content."
Would people agree with the MySQL guys on this? In particular, that this
is a "typical situation" for many webapps?
> Has anyone looked at the details of the test case that
> MySQL uses to claim that this is a good idea?
I emailed the author of the eWeek benchmarks asking for more
information. My guess is that the benchmark results benefit from the
query cache because it executes exactly the same query over and over
again (e.g. selecting the same product from the database every time, not
simulating typical user behavior by selecting random products). If that
is the case, the results are clearly irrelevant.
> Has it got any similarity to your own usage patterns?
I would be very interested to hear about this as well.
> Now, there are notions of "prepared statements" in many access APIs
> that fit this description, and in fact the underlying capability exists
> in the backend --- we've just not gotten around to building the
> interfaces to tie it all together. *That* would be worth working on.
Okay, I'll take a look at this...
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-02-27 06:37:17|
|Subject: Re: Refactoring of command.c |
|Previous:||From: Dann Corbit||Date: 2002-02-27 06:03:33|
|Subject: Re: eWeek Poll: Which database is most critical to your|