pgpool (which makes some rather questionable claims IMO); any decent web
application language/environment will support connection pooling.
That's why it should not be tied to something specific as pgpool.
If you want performance, which is the case here, usually you have a
webserver serving
1) The materialized data is available in 3 different forms; a list, a
detail
view, and a spreadsheet. Each form as somewhat different columns and
different rules about ordering, which would likely confuse an SQC
planner.
In this implementation, all 3 forms are able to share the same cache.
If it was in pgpool or something similar, I could devote a separate
machine just for caching results leaving the db server untouched.
BUT you would be limited to caching complete queries. There is a more
efficient strategy...
---(end of
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.
How does putting it into PGPool make it any less trivial for people to
use?
The answers are at
Maybe add an order by artist to force a groupaggregate ?
Hi all, a small question:
I've got this table songs and an index on column artist. Since
there's about
one distinct artist for every 10 rows, it would be nice if it could use
this
index when counting artists. It doesn't however:
Russell Smith [EMAIL PROTECTED] writes:
The Index does not store NULL values
This is false.
Though the fact that NULL values are indexed in postgres doesn't help with
this poster's actual problem.
--
greg
---(end of broadcast)---
TIP 2: you
