Chris <chris@bitmead.com> writes:
>> * Cache most recent query plan(s) [prepare]
> I havn't been following what this is about, but
> any implementation of caching query plans should
> be careful about pg_class.relhasindex and
> pg_class.relhassubclass, otherwise reuse of
> query plans could give incorrect results, _maybe_,
> depending on what you are planning here.
Well, of course the cached plan would only be good as long as you
weren't changing the database schema underneath it. I'm not sure
how far the system ought to go to prevent the user from continuing
to use a no-longer-valid plan ... exact detection of trouble seems
impractical, but I'm not thrilled with a "let the programmer beware"
approach either.
Also, assuming that we do have some trouble detection mechanism, should
we reject subsequent attempts to use the cached plan, or automatically
re-do the plan on next use? If we kept around source or querytree form
of the original query, it ought to be possible to re-make the plan.
This would let us adopt a fairly simple trouble-detection mechanism that
would err in the direction of re-planning too much; say just replan on
any relcache flush for the relevant tables & indices. (If we're going
to raise an error, that test would be much too prone to raise errors
unnecessarily.)
This seems closely related to Jan's TODO item about recompiling rules
when the DB schema changes, too.
regards, tom lane