Re: Postgresql performance in production environment - Mailing list pgsql-general

From Magnus Hagander
Subject Re: Postgresql performance in production environment
Date
Msg-id 46C828D7.2@hagander.net
Whole thread Raw
In response to Re: Postgresql performance in production environment  ("Phoenix Kiula" <phoenix.kiula@gmail.com>)
List pgsql-general
Phoenix Kiula wrote:
> On 19/08/07, Magnus Hagander <magnus@hagander.net> 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

pgsql-general by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Postgresql performance in production environment
Next
From: Hannes Dorbath
Date:
Subject: Re: Seeking datacenter PITR backup procedures [RESENDING]