Re: Copy path in Dynamic programming

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: vamsi krishna <vamsikrishna1902(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Copy path in Dynamic programming
Date: 2010-07-27 20:24:56
Message-ID: 13343.1280262296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
> <vamsikrishna1902(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-27 20:48:50 Re: do we need to postpone beta4?
Previous Message Tom Lane 2010-07-27 20:09:43 Re: do we need to postpone beta4?