From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Function result cacheing |
Date: | 2002-08-17 04:18:28 |
Message-ID: | 29521.1029557908@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-08-17 06:30:01 | Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke |
Previous Message | Bruce Momjian | 2002-08-17 04:17:13 | Re: Open 7.3 items |