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.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.
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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
