RE: [Spark SQL][reopen SPARK-16951]:Alternative implementation of NOT IN to Anti-join

[Shuang, Linna1]

Hi Talebzadeh,

Thank you reply, the background is to use a common benchmark(here we use TPC-H) 
to compare different platform’s performance.

Our current solution is

  1.  remove Q16 out of test
  2.  rewrite Q16 without using “NOT IN”

Both solutions are not perfect. For Solution b which is suggested by the JIRA, 
the common benchmark already being changed, sometimes the result will be 
questioned when comparing with other platforms. In my understanding, the best 
solution is to find a better way to support “NOT IN” in Spark SQL, instead of 
suggesting not to use “NOT IN” in query.

Thanks,
Linna

From: Mich Talebzadeh 
Sent: Tuesday, May 12, 2020 11:16 PM
To: Shuang, Linna1 
Cc: user@spark.apache.org
Subject: Re: [Spark SQL][reopen SPARK-16951]:Alternative implementation of NOT 
IN to Anti-join

Hi Linna,

Please provide a background to it and your solution. The assumption is that 
there is a solution. as suggested.

Thanks,


Dr Mich Talebzadeh



LinkedIn  
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw



http://talebzadehmich.wordpress.com



Disclaimer: Use it at your own risk. Any and all responsibility for any loss, 
damage or destruction of data or any other property which may arise from 
relying on this email's technical content is explicitly disclaimed. The author 
will in no case be liable for any monetary damages arising from such loss, 
damage or destruction.




On Tue, 12 May 2020 at 04:47, Shuang, Linna1 
mailto:linna1.shu...@intel.com>> wrote:
Hello,

This JIRA (SPARK-16951) already being closed with the resolution of “Won’t Fix” 
on 23/Feb/17.

But in TPC-H test, we met performance issue of Q16, which used NOT IN subquery 
and being translated into broadcast nested loop join. This query uses almost 
half time of total 22 queries. For example, 512GB data set, totally execution 
time is 1400 seconds, while Q16’s execution time is 630 seconds.

TPC-H is a common spark sql performance benchmark, this performance issue will 
be met usually. Is it possible to reopen this JIRA and fix this issue?

Thanks,
Linna

Re: [Spark SQL][reopen SPARK-16951]:Alternative implementation of NOT IN to Anti-join

[Mich Talebzadeh]

Hi Linna,

Please provide a background to it and your solution. The assumption is
that there is a solution. as suggested.

Thanks,

Dr Mich Talebzadeh



LinkedIn * 
https://www.linkedin.com/profile/view?id=AAEWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw
*



http://talebzadehmich.wordpress.com


*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Tue, 12 May 2020 at 04:47, Shuang, Linna1 
wrote:

> Hello,
>
>
>
> This JIRA (SPARK-16951) already being closed with the resolution of “Won’t
> Fix” on 23/Feb/17.
>
>
>
> But in TPC-H test, we met performance issue of Q16, which used NOT IN
> subquery and being translated into broadcast nested loop join. This query
> uses almost half time of total 22 queries. For example, 512GB data set,
> totally execution time is 1400 seconds, while Q16’s execution time is 630
> seconds.
>
>
>
> TPC-H is a common spark sql performance benchmark, this performance issue
> will be met usually. Is it possible to reopen this JIRA and fix this issue?
>
>
>
> Thanks,
>
> Linna
>
>
>

[Spark SQL][reopen SPARK-16951]:Alternative implementation of NOT IN to Anti-join

[Shuang, Linna1]

Hello,

This JIRA (SPARK-16951) already being closed with the resolution of "Won't Fix" 
on 23/Feb/17.

But in TPC-H test, we met performance issue of Q16, which used NOT IN subquery 
and being translated into broadcast nested loop join. This query uses almost 
half time of total 22 queries. For example, 512GB data set, totally execution 
time is 1400 seconds, while Q16's execution time is 630 seconds.

TPC-H is a common spark sql performance benchmark, this performance issue will 
be met usually. Is it possible to reopen this JIRA and fix this issue?

Thanks,
Linna