Phoenix Kiula wrote: > On 19/08/07, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote: >> Phoenix Kiula wrote: > >> There are ways to do this, but if you can't just use timeouts to expire >> from the cache, things can become pretty complicated pretty fast. But >> perhaps you can isolate some kinds of queries that can be cached for <n> >> minutes, and keep the rest without caching? > > > Thanks. In fact we need caching on a very specific part of our > application, for only three queries which hit the DB hard with > thousands of simultaneous SELECTs. > > Do pgmemcache or pgbouncer allow for very specific usage? Both look > way too complex. I don't mind the initial headachy setup and config, > but then I would like the system to hum on its own, and the querying > should be simple and intuitive. > > I need a simple mechanism to query the cache, and invalidate a > specific query in the cache when the underlying table is UPDATED so > that the query gets cached afresh when issued later. (And a way to use > this mechanism through PHP or Perl would be splendid). > > TIA for any tips! You can use LISTEN and NOTIFY to clear the cache, if you have many clients that can cause cache invalidations. If you only have a single app that can update the database, you can invalidate the cache from that applications code directly (such as using asp.net output caching if you were doing it in .net). I've implemented the prior a couple of times, but it does get a bit complex. The second part would be easier, but I don't have any direct pointers on that since it depends on the app development framework you're using. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
