Thread: 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:
Thanks!
PlannedStmt * pltl = (PlannedStmt *) linitial(plantree_list);
Plan *pl = pltl->planTree;
Plan *pl = pltl->planTree;
char *s;
s = nodeToString(pl);
s = nodeToString(pl);
How to restore from this s to Plan?
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:
Now the second connection comes, if the server generate the same sub plan i could just read the first sub plan's 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:
Plan *subPlan1;
....
char *s;
s = nodeToString(subPlan1);
//then store s into a text file subPlan1.txt on disk.
//and store the sub plan's execution result
....
Then the first connection closed.....
char *s;
s = nodeToString(subPlan1);
//then store s into a text file subPlan1.txt on disk.
//and store the sub plan's execution result
....
Now the second connection comes, if the server generate the same sub plan i could just read the first sub plan's result:
Plan *subPlan2;
....
char *s ;//then read s from the text file subPlan1.txt on disk
Plan *subPlan1 = deserialized(s);
bool equ = equal(plan1,plan2); //which also can't work for Plan node
if(equ){
//then return the cached first connection's result;
}
...
Then should I write deserialized(s) codes and another equal(void *, void*) function to support Plan node?....
char *s ;//then read s from the text file subPlan1.txt on disk
Plan *subPlan1 = deserialized(s);
bool equ = equal(plan1,plan2); //which also can't work for Plan node
if(equ){
//then return the cached first connection's result;
}
...
2010/9/3 Tom Lane <tgl@sss.pgh.pa.us>
sunpeng <bluevaley@gmail.com> writes:You can't. The fact that there's nodeToString support for all Plan node
> 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?
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
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