[Pgpool-hackers] cache for pgpool

Jim C. Nasby jnasby at pervasive.com
Tue May 16 20:34:34 UTC 2006


On Tue, May 16, 2006 at 09:35:55PM +0200, Jean-Max Reymond wrote:
> 2006/5/16, David Boreham <david_list at boreham.org>:
> >
> >
> >
> >  There's a ton of poorly written applications that would fall flat on
> > their face if not for caching the results of queries. There's even some
> > well written ones that need to rely on this, especially since PostgreSQL
> > doesn't really support materialized views.
> >
> > Plus I figure anything that helps migration from MySQL to PostgreSQL is
> > a Good Thing(tm). :)
> >
> >  Oh sure. Some of us make a nice living fixing broken applications and
> > writing caching layers, replication features etc ;)
> >  I just wanted to be sure that we're on the same page here : is the OP
> > really asking about external caching,
> >  or does he have the notion that MySQL is somehow much better at processing
> > his queries than
> >  PG would be ? (possibly true, but also possibly false and based on
> > incorrect assumptions about
> >  how PG works vs. the alternative).
> 
> imagine a page with three select count(*) from blabla.
> this page is the home page and loaded 2 millions times/day
> no chance for Postgres :-(

And do you *really* need an exact, up-to-the-second count on the home
page? If it's truely just 'SELECT count(*) FROM table', you could easily
just SELECT reltuples FROM pg_class WHERE relname='table', which would
be up-to-date as of the last analyze.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


More information about the Pgpool-hackers mailing list