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=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw>* 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 <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 > > >
