"Neil Conway" <neilc@samurai.com> writes
> PostgreSQL should invalidate a cached query plan when one of the objects
> the plan depends upon is modified.
It just comes into my mind that current cache invalidation implementation
may need to consider the future query result cache.
The question comes like this: for a simple query (i.e., the query without
any function call, on a single relation, etc), the result cache is not very
difficult to do in my understanding, the sketch is here:
(1) result set is only valid for queries within a serializable transaction;
(2) result set is reusable if the whole where-condition is matched - for
simplicity;
(3) discard the cache result is the target relation is updated in the same
transaction;
We cache ctids or the real tuples. And we develop a new scan method, say
T_ResultSetScan on the result set.
A problem is araised if the where-condition include a function. Two queries
looks the same, but the function they called might be different at this time
... the cached plans invalidation mechanism could help to detect this.
Regards,
Qingqing