Re: Function result cacheing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Function result cacheing
Date
Msg-id 29521.1029557908@sss.pgh.pa.us
Whole thread Raw
In response to Function result cacheing  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Function result cacheing  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Obviously this is not a 7.3 item, but would people support such 
> functionality going into a future version?

Actually, I wouldn't.  I can think of very few situations where
such caching is useful, and I don't believe that the mechanism required
would pay for itself.  In the cases where a cache does make sense,
it's sufficiently application-specific that a generic "cache on a key
consisting of the function arguments" isn't the right thing anyway;
you'll find you want some internal logic to decide what to cache and
what key to use to retrieve it.  Furthermore, a generic cache will have
no clue whatever about cache-invalidating events, thus further
restricting its usefulness.  (Your suggestion of "flush at transaction
end" is too short-term for most applications, too long-term for some,
and just right for hardly any.)

Build the cache internally to your function if you need it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Open 7.3 items
Next
From: Curt Sampson
Date:
Subject: Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke