On Wed, 17 Apr 2002 14:34:45 -0700
"Dann Corbit" <DCorbit@connx.com> wrote:
> However, I've tentatively decided that I think the best
> way to go forward is to rewrite this code. IMHO the utility of
> plans cached in shared memory is fairly limited, but the
> code that implements this adds a lot of complex to the patch.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> DC% Why do you imagine that the utility is limited?
(1) It's difficult to tell whether a given plan has already been prepared: the server could have been restarted in
themean-time, for example. We could allow app developers to check if a given has already been prepared, but that's
inconvenient, and the benefits seem fairly small.
(2) Shared memory is a bad storage location for variable-sized data, like query plans. What happens if you're asked
to cache a plan larger than the free space in the shared cache? You could perhaps free up some space by removing
another entry, but that means that every invocation of EXECUTE needs to be prepared for the target plan to have been
evicted from the cache -- which is irritating.
(3) Managing concurrent access to the shared cache may (or may not) be a performance issue.
I'm not saying it's a bad idea, I just think I'd like to
concentrate on the locally-cached plans for now and see if
there is a need to add shared plans later.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> I'm planning to re-implement PREPARE/EXECUTE with support only
> for locally-prepared plans, using the existing patch as a
> guide. The result should be a simpler patch -- once it's
> in CVS we can worry about more advanced plan caching
> techiques. Any complaints/comments on this plan?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> DC% Why not allow both kinds and make it configurable...
> DC% local/shared/both.
That's what the current patch does.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
