On Sun, 2007-02-18 at 18:19 -0500, Tom Lane wrote:
While thinking about having a centralized plan cache for managing plan
invalidation, I got annoyed again about the fact that the executor needs
access to the Query tree. This means that we'll be storing *three*
representations of any cached
Simon Riggs [EMAIL PROTECTED] writes:
After looking over the code it seems that the executor needs a limited
subset of the Query fields, namely
...
which I think we should put into a new TopPlan node type.
All else sounds good, but why would we be caching a plan that used these
fields?
Um,
On Sun, 18 Feb 2007, Tom Lane wrote:
We've repeatedly discussed getting rid of execution-time access to the
Query structure --- here's one old message about it:
http://archives.postgresql.org/pgsql-hackers/1999-02/msg00388.php
and here's a recent one:
Gavin Sherry wrote:
On Sun, 18 Feb 2007, Tom Lane wrote:
Comments, objections? Also, any thoughts about the names to use for
these new node types? As I commented last year, I'm not completely
happy with TopPlan because it won't actually be a subtype of Plan,
but I don't have a better idea.
Mark Kirkwood [EMAIL PROTECTED] writes:
Gavin Sherry wrote:
On Sun, 18 Feb 2007, Tom Lane wrote:
Comments, objections? Also, any thoughts about the names to use for
these new node types? As I commented last year, I'm not completely
happy with TopPlan because it won't actually be a subtype
Tom Lane [EMAIL PROTECTED] writes:
Comments, objections? Also, any thoughts about the names to use for
these new node types? As I commented last year, I'm not completely
happy with TopPlan because it won't actually be a subtype of Plan,
but I don't have a better idea. Also I'm unsure what
