>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 guess the performance increase is that you can spend $10,000 on a
developer, or $10,000 on hardware, and for the most part get a more
reliable result the second way. MemcacheD is fine(ish), but it's not a
panacea, and it's more than easy to shoot yourself in the foot with it.
Caching is hard enough that lots of people do it badly - I'd rather use
an implementation from the PG team than almost anywhere else.
>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.
>
>
>
Well the point surely is to _remove_ complexity from the application,
which is written by God Knows Who, and put it in the DB, which is
written by God And You. And you can still have ACID (cached data is not
the same as stale data, although once you have the former, the latter
can begin to look tempting sometimes).
M