Re: [Postgres-xc-developers] ExecRemoteQuery

[Ashutosh B. <ash...@en...>]

It should be part of 1.1 as well. It was done to support projection out of
RemoteQuery node.


On Tue, Aug 13, 2013 at 7:17 AM, Nikhil Sontakke <ni...@st...>wrote:

> Hi Ashutosh,
>
> I guess you have changed it in pgxc head? I was looking at 103 and 11
> branches and saw this. In that even ExecRemoteQuery seems to have an issue
> wherein it's not using the appropriate context.
>
> Regards,
> Nikhils
>
> Sent from my iPhone
>
> On Aug 12, 2013, at 9:54 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>
> Welcome to the mess ;) and enjoy junk food.
>
> Sometime back, I have changed ExecRemoteQuery to be called in the same
> fashion as other Scan nodes. So, you will see ExecRemoteQuery calling
> ExecScan with RemoteQueryNext as the iterator. So, I assume your comment
> pertains to RemoteQueryNext and its minions and not ExecRemoteQuery per say!
>
> This code needs a lot of rework, removing duplications, using proper way
> of materialisation, central response handler and error handler etc. If we
> clean up this code, some improvements in planner (like using MergeAppend
> plan) for Sort, will be possible. Regarding materialisation, the code uses
> a linked list for materialising the rows from datanodes (in case the same
> connection needs to be given to other remote query node), which must be
> eating a lot of performance. Instead we should be using some kind of
> tuplestore there. We actually use tuplestore (as well) in the RemoteQuery
> node; the same method can be used.
>
>
> On Sat, Aug 10, 2013 at 10:48 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> Hi,
>>
>> Have a Query about ExecRemoteQuery.
>>
>> The logic seems to have been modeled after ExecMaterial. ISTM, that it
>> should have been modeled after ExecScan because we fetch tuples, and those
>> which match the qual should be sent up. ExecMaterial is for materializing
>> and collecting and storing tuples.
>>
>> Can anyone explain? The reason for asking this is I am suspecting a big
>> memory leak in this code path. We are not using any expression context nor
>> we are freeing up tuples as we scan for the one which qualifies.
>>
>> Regards,
>> Nikhils
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company