Обсуждение: How to restore a Plan from a stored plan text?

I've used the following codes to translate the PlannedStmt node to a char string:
  I noticed using func parseNodeString() in /backends/nodes/readfuncs.c can't work, for example there is no codes translating into Agg node, should I write my code to parse this string back into PlannedStmt node?
  Thanks!

sunpeng <bluevaley@gmail.com> writes:
> I've used the following codes to translate the PlannedStmt node to a char
> string:
> PlannedStmt * pltl = (PlannedStmt *) linitial(plantree_list);
> Plan *pl = pltl->planTree;
> char       *s;
> s = nodeToString(pl);

>  How to restore from this s to Plan?

You can't.  The fact that there's nodeToString support for all Plan node
types is only intended as a debugging aid --- there's no intention that
it should be possible to serialize and deserialize plans this way.

You didn't say what it is you actually hope to accomplish, but maybe
asking plancache.c to store the plan for you would do.

            regards, tom lane

Thanks for your help!The motivation is that I try to find the most used sub plan ,and cach the sub plan's execution result and  store sub plan itself on disk. Even the sub plan's connection is closed, the consequent connection with the same sub plan could utilize the stored cached result.
For example.
The first connection comes and according history information we find the most used sub plan, and after execution, i serialize this sub plan node into a text file and stored the sub plan's execution result on disk:
Then the first connection closed.
Now the second connection comes, if the server generate the same sub plan i could just read the first sub plan's result:
Then should I write deserialized(s) codes and another equal(void *, void*) function to support Plan node?

sunpeng <bluevaley@gmail.com> writes:
> Thanks for your help!The motivation is that I try to find the most used sub
> plan ,and cach the sub plan's execution result and  store sub plan itself on
> disk. Even the sub plan's connection is closed, the consequent connection
> with the same sub plan could utilize the stored cached result.

This is not particularly a good idea, at least not without a whole lot
of *other* infrastructure.  How will you know if the plan has been
obsoleted by table changes?  Even without considering that, how will you
know when the cached result is obsoleted by data changes?

You might want to consult the PG archives for previous discussions about
shared plan caches.  I think the previous proposals involved keeping
things in shared memory not on disk, but they otherwise had many of the
same problems as this.  There have also been periodic discussions about
caching function execution results, which also seems closely related.

            regards, tom lane