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

Re: cacheing metadata

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: pg(at)fastcrypt(dot)com
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: cacheing metadata
Date: 2004-06-03 21:30:07
Message-ID: 40BF985F.1000802@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Dave Cramer wrote:
> There is some interest in caching meta-data. I am wondering what the
> community thinks of the idea.

Are there really metadata-query-heavy apps out there that would benefit? 
  Do you have an example of one? I'd have thought that most if not all 
of the metadata-related tables would all be sitting in cache anyway.

It seems like this is a special case of the more general "I run 
expensive queries and don't want to rerun them to pick up changes". And 
a very special case at that -- metadata doesn't usually change very often.

If the app is essentially a UI frontend I'd say you could get away with 
caching results in the app (not the driver) and having a "reload" button.

If the app really needs up-to-the-moment metadata state to control 
whatever actions that follow, it'll need to hit the DB with the full 
metadata query while in a transaction to get the right isolation 
characteristics, won't it?

> Notionally it would be used to speed up DataBaseMetaData queries. It
> will require some work on the backend to create triggers on schema
> changes. This is being considered as we speak.

If you're going to be adding support triggers to every DB anyway, why 
not bite the bullet and do a stored proc that maintains a cache table of 
materialized metadata, or something similar?

-O

In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-06-03 21:42:41
Subject: Re: cacheing metadata
Previous:From: Manju MaliyekkalDate: 2004-06-03 10:24:36
Subject: asking help

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