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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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