On Tue, Mar 10, 2015 at 3:09 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Mar 10, 2015 at 6:50 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
> wrote:
>>
>> On Tue, Mar 10, 2015 at 1:38 AM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> >
>> > Assuming previous patch is in right direction, I have enabled
>> > join support for the patch and done some minor cleanup of
>> > patch which leads to attached new version.
>>
>> Is this patch handles the cases where the re-scan starts without
>> finishing the earlier scan?
>>
>
> Do you mean to say cases like ANTI, SEMI Join (in nodeNestLoop.c)
> where we scan the next outer tuple and rescan inner table without
> completing the previous scan of inner table?
Yes.
> I have currently modelled it based on existing rescan for seqscan
> (ExecReScanSeqScan()) which means it will begin the scan again.
> Basically if the workers are already started/initialized by previous
> scan, then re-initialize them (refer function ExecReScanFunnel() in
> patch).
>
> Can you elaborate more if you think current handling is not sufficient
> for any case?
From ExecReScanFunnel function it seems that the re-scan waits till
all the workers
has to be finished to start again the next scan. Are the workers will
stop the current
ongoing task? otherwise this may decrease the performance instead of
improving as i feel.
I am not sure if it already handled or not, when a worker is waiting
to pass the results,
whereas the backend is trying to start the re-scan?
Regards,
Hari Babu
Fujitsu Australia