>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
