Hi Jasbir

I don't think the Apache mailing lists allows you to send attachments, except 
may be text files. (The txt file made it through).


In your Operator Profile, you'll see two columns... %Fragment Time and 
%QueryTime

Taking your mouse over those table headers should show you a description of the 
two.


%Fragment time is the fraction of time spent by threads of that Major Fragment 
for a specific operator. This simply means which operator did the threads of a 
major fragment spend most time on.


%QueryTime is teh fraction of time spent by the threads of ALL the Major 
fragments for a specific operator. This simply means which operator, 
implicitly, consumed the most CPU resources.


>From the latter, it appears that the HashJoin (03-xx-04) and Parquet Scan 
>(03-xx-06) are the biggest bottlenecks. THe unordered receiver is not the 
>bottleneck in the query.


~ Kunal



________________________________
From: [email protected] <[email protected]>
Sent: Friday, June 2, 2017 12:13:21 AM
To: [email protected]; [email protected]
Cc: [email protected]; [email protected]; 
[email protected]
Subject: RE: [External] Re: UNORDERED_RECEIVER taking 70% of query time

Hi,

Please find the attached query profile.

I am running Drill in local mode on my laptop with default memory allocation to 
Apache Drill.

Let me know if you are not able to find the attachment.

Also, sending the file in RAR format.

Regards,
Jasbir Singh


-----Original Message-----
From: Abhishek Girish [mailto:[email protected]]
Sent: Friday, June 02, 2017 11:00 AM
To: [email protected]
Subject: [External] Re: UNORDERED_RECEIVER taking 70% of query time

Attachment hasn't come through. Can you upload the query profile to some cloud 
storage and share a link to it?

Also, please share details on how large your dataset is, number of Drillbits, 
memory and other configurations.


On Thu, Jun 1, 2017 at 10:18 PM, <[email protected]> wrote:

> Hi,
>
>
>
> I am running a simple query which performs JOIN operation between two
> parquet files and it takes around 3-4 secs and I noticed that 70% of
> the time is used by UNORDERED_RECEIVER.
>
>
>
> Sample query is –
>
>
>
> select sum(sales),week from dfs.`C:\parquet-location\
> F8894180-AFFB-4803-B8CF-CCF883AA5AAF-Search_Snapshot_Data.parquet`
> where model_component_id in(
>
> select model_component_id from
> dfs.`C:\parquet-location\poc48k.parquet`)
> group by week
>
>
>
>
>
> Can we somehow reduce unordered receiver time?
>
>
>
> Please find the below screenshot of Visualized plan
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
> Where allowed by local law, electronic communications with Accenture
> and its affiliates, including e-mail and instant messaging (including
> content), may be scanned by our systems for the purposes of
> information security and assessment of internal compliance with Accenture 
> policy.
> ____________________________________________________________
> __________________________
>
> www.accenture.com<http://www.accenture.com>
>

________________________________

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
______________________________________________________________________________________

www.accenture.com<http://www.accenture.com>

Reply via email to