Re: Caching of Queries

From: Matt Clark <matt(at)ymogen(dot)net>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: 'Aaron Werman' <awerman2(at)hotmail(dot)com>, 'Scott Kirkwood' <scottakirkwood(at)gmail(dot)com>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Caching of Queries
Date: 2004-09-27 20:30:31
Message-ID: 41587867.4090505@ymogen.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


>It might be easiest to shove the caching logic into pgpool instead.
>
>...
>
>When pg_pool is told to cache a query, it can get a table list and
>monitor for changes. When it gets changes, simply dumps the cache.
>
>
>
>
It's certainly the case that the typical web app (which, along with
warehouses, seems to be one half of the needy apps), could probably do
worse than use pooling as well. I'm not well up enough on pooling to
know how bulletproof it is though, which is why I included it in my list
of things that make me go 'hmm....'. It would be really nice not to
have to take both things together.

More to the point though, I think this is a feature that really really
should be in the DB, because then it's trivial for people to use.
Taking an existing production app and justifying a switch to an extra
layer of pooling software is relatively hard compared with grabbing data
from a view instead of a table (or setting a variable, or adding a tweak
to a query, or however else it might be implemented).

Eminiently doable in pgpool though, and just the right thing for anyone
already using it.

M

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rod Taylor 2004-09-27 20:37:34 Re: Caching of Queries
Previous Message Matt Clark 2004-09-27 20:19:12 Re: Caching of Queries