Re: Is Parallelism happening at INSERT level?

We have not gotten any updates from the OP, but even optimizer estimation is good but there could still be problem due to inefficient selecting cluster size and memory pressure. Even it is One-pass hash join there can be lots of (“unexpected”) “direct path write temp” which related to these factors.

I have covered them in the post:

https://chinaraliyev.wordpress.com/2020/05/23/serial-hash-join-performance/

On Thu, May 7, 2020 at 11:28 AM Lothar Flatz <l.flatz_at_bluewin.ch> wrote:

> Thanks Jonathan, I think this is really useful. I already wondered before
> about missing bloom filters. :-)
>
> Am 06.05.2020 um 19:21 schrieb Jonathan Lewis:
>
>
> Until 19c a query that uses a Bloom filter will "lose" the Bloom filter
> when it's changed to "insert as select".
> However CTAS does work, and there is a patch, that allows insert /*+
> append */ as select to use a Bloom filter.
>
> See blog and comments:
> https://jonathanlewis.wordpress.com/2016/07/08/dml-and-bloom/
>
> Regards
> Jonathan Lewis
>
>
>
>
>
> On Wed, May 6, 2020 at 4:04 PM Lothar Flatz <l.flatz_at_bluewin.ch> wrote:
>
>> Hi,
>>
>> I wonder if a Bloom Filter could be used on sce. Would that be faster
>> than probing? I would think so ...
>> There seems to be many rows not surviving the join.
>>
>> Regards
>>
>> Lothar
>>
>>
>

-- 
*Chinar Aliyev*


Visit My         :Blog <http://chinaraliyev.wordpress.com/>
Let's Connect -
<http://fr.linkedin.com/pub/mohamed-houri/11/329/857/>*Linkedin
Profile <https://www.linkedin.com/in/chinaraliyev/>*

My Twitter <https://twitter.com/MohamedHouri>      - ChinarAliyev
<https://twitter.com/ChinarAliyev>

--
http://www.freelists.org/webpage/oracle-l