Thread: Copy path in Dynamic programming
Hi everybody
I am doing a modification to Dynamic programming algorithm in postgreSQL. I want to re-use a plan of one " joinrels" for another of the same level.
For example,
if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and set B={6,7,8,9,10}.
I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.
But for this I need to create a relation that holds all the paths for {6,7,8,9,10}.
I cannot just copy the relation holding join paths from setA. I need to create a new join relations using build_join_rel(). But I cannot do add_paths_to_joinrel() because that is the default path creation procedure. Instead I must be copying the paths of joinrel fo setA.
So what I am doing now is :
1) Access the join relation for setA = {1,2,3,4,5}.
2) Pathlist = pathlist of joinrel(A).
3) foreach path "p" in pathlist of joinrel(A){
create new path "new_p" from path "p".
left_child(new_p) = recursively copy from left child(p)
right_child(new_p) = recursively copy from right child(p).
}
4)But to do step 3 I need to know how to create pathkeys and I need to do the copy recursively, as I am trying to copy the path tree from top to bottom.
Errors I get in doing this:
ERROR: variable not found in subplan target lists
Please give some insight. And please discuss with me on how to go about doing the path copy.
Thanks
Vamsi
On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
<vamsikrishna1902@gmail.com> wrote:
> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
> set B={6,7,8,9,10}.
>
> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.
I don't think that makes any sense.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
> <vamsikrishna1902@gmail.com> wrote:
>> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
>> set B={6,7,8,9,10}.
>>
>> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.
> I don't think that makes any sense.
Yeah. The theoretical problem is that substituting setB for setA could
change the estimated rowcounts, and thus you should not use the same
path. The practical problem is that the Path datastructure doesn't
store the specific quals to be used, in general --- it relies on the
RelOptInfo structures to remember which quals need to be checked during
a scan. So you can't just "copy the path and substitute some other
qual". You could maybe do it if you copied the entire planner
workspace, but that's not too practical from a memory consumption
standpoint. Not to mention that a lot of the node types in question
don't have copyfuncs.c support, which is only partly laziness --- it's
also the case that copyObject() is incapable of coping with circular
linkages, and the planner data structures are full of those.
regards, tom lane