Re: Caching of Queries
От | Steve Atkins |
---|---|
Тема | Re: Caching of Queries |
Дата | |
Msg-id | 20040927205345.GA29554@gp.word-to-the-wise.com обсуждение исходный текст |
Ответ на | Re: Caching of Queries (Matt Clark <matt@ymogen.net>) |
Ответы |
Re: Caching of Queries
|
Список | pgsql-performance |
On Mon, Sep 27, 2004 at 09:19:12PM +0100, Matt Clark wrote: > >Basically you set a default in seconds for the HTML results to be > >cached, and then have triggers set that force the cache to regenerate > >(whenever CRUD happens to the content, for example). > > > >Can't speak for Perl/Python/Ruby/.Net/Java, but Cache_Lite sure made a > >believer out of me! > > > > > > > Nice to have it in a library, but if you want to be that simplistic then > it's easy in any language. What if a process on server B modifies a n > important value that server A has cached though? Coherency (albeit that > the client may choose to not use it) is a must for a general solution. memcached is one solution designed for that situation. Easy to use from most languages. Works. Lets you use memory on systems where you have it, rather than using up valuable database server RAM that's better spent caching disk sectors. Any competently written application where caching results would be a suitable performance boost can already implement application or middleware caching fairly easily, and increase performance much more than putting result caching into the database would. I don't see caching results in the database as much of a win for most well written applications. Toy benchmarks, sure, but for real apps it seems it would add a lot of complexity, and violate the whole point of using an ACID database. (Caching parse trees or query plans, though? It'd be interesting to model what effect that'd have.) Cheers, Steve
В списке pgsql-performance по дате отправления: