Re: eWeek Poll: Which database is most critical to your
От | Neil Conway |
---|---|
Тема | Re: eWeek Poll: Which database is most critical to your |
Дата | |
Msg-id | 1014790904.605.59.camel@jiro обсуждение исходный текст |
Ответ на | Re: eWeek Poll: Which database is most critical to your (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: eWeek Poll: Which database is most critical to your
|
Список | pgsql-hackers |
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) > applications. 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... Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления: