Skip site navigation (1) Skip section navigation (2)

Re: Caching of Queries

From: Rod Taylor <pg(at)rbt(dot)ca>
To: matt(at)ymogen(dot)net
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 17:37:51
Message-ID: 1096306670.40463.173.camel@jester (view raw or flat)
Thread:
Lists: pgsql-performance
> So yeah, here's another vote for this feature.  It doesn't even need to
> happen automagically to be honest, so long as it's really simple for the
> client to turn on (preferably per-statement or per-table).

It might be easiest to shove the caching logic into pgpool instead.

Create an extension of EXPLAIN which returns data in an easy to
understand format for computers so that pgpool can retrieve information
such as a list of tables involved, 

Extend LISTEN to be able to listen for a SELECT on a table --
replacement for dynamically adding triggers to send a notify on inserts,
updates, deletes.

Create some kind of generic LISTEN for structural changes. I know SLONY
could make use of triggers on ALTER TABLE, and friends as well.


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.


In response to

Responses

pgsql-performance by date

Next:From: Gaetano MendolaDate: 2004-09-27 18:09:46
Subject: best statistic target for boolean columns
Previous:From: Matt ClarkDate: 2004-09-27 17:20:48
Subject: Re: Caching of Queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group