Re: [HACKERS] parallelize queries containing initplans

On Thu, Nov 16, 2017 at 10:44 PM, Robert Haas wrote: > On Thu, Nov 16, 2017 at 5:23 AM, Kuntal Ghosh > wrote: >> I've tested the above-mentioned scenario with this patch and it is >> working fine. Also, I've created a text column named

Re: [HACKERS] parallelize queries containing initplans

On Thu, Nov 16, 2017 at 3:34 PM, Amit Kapila wrote: > On Wed, Nov 15, 2017 at 12:25 AM, Robert Haas wrote: >> On Tue, Nov 14, 2017 at 11:00 AM, Tom Lane wrote: >>> Yeah, I'm sure it is. I have a vague recollection that there

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 10:37 AM, Robert Haas wrote: > The problem would happen if the plan for InitPlan $1 in the above > example itself referenced a parameter from an upper query level, and > the value of that parameter changed, and then this section of the plan > tree

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila wrote: > I think this would have been a matter of concern if we use initplans > below Gather/Gather Merge. The patch uses initplans which are between > current query level and root. So, I think we don't need to reevaluate >

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 2:39 AM, Robert Haas wrote: > On Sat, Nov 11, 2017 at 7:19 AM, Amit Kapila wrote: >> I have tried to follow the practice we have used for param extern >> params (SerializeParamList is in params.c) and most of the handling of