Re: different plan with insert/select

Nenad,

I didn't have a bug number relating to the DCL/LAT thing, just an observation I had from a sample piece of code that got the wrong results.

If it's outer joins to laterval views possibly it relates to the equivalent of a restriction on "join predicate pushdown" - do the predicate sections show exactly the same correlation columns for the two accesses into the VW_LAT when compared across the two execution plans, or does the insert plan lose a correlation column on vw_lat usage that shows the huge cost and cardinality ?

Regards
Jonathan Lewis

On Wed, Jun 24, 2020 at 12:06 PM Noveljic Nenad <nenad.noveljic_at_vontobel.com> wrote:

> - The source of VW_LAT are outer joins. It is an ANSI query, but without
> any explicit lateral references.
>
>
>
> - Bypassed unnestings and/or lateral view decorrelations might explain
> less join permutations. I’ll examine the optimizer trace.
>
>
>
> - Select plan runs in 10s, insert/select is running for hours.
>
>
>
> - In a couple of hours I’ll be able to compare the result sets.
>
>
>
> - You mean this: Plan Regression with VW_DCL (Lateral View Decorrelation)
> in Explain Plan New Transformation in 12c Optimizer (Doc ID 2361393.1) ?
>
> The optimizer indeed comes up with the poor plan for the select with
> "_optimizer_ansi_rearchitecture" = false;
>
> I'd say, DCL is done for select, but apparently has some limitations with
> CTAS/INS. Rewriting the query to the Oracle syntax might be a workaround.
>
>
>
> Best regards,
>
>
>
> Nenad
>
>
>
> http://nenadnoveljic.com/blog/
>
>
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
> Behalf Of *Jonathan Lewis
> *Sent:* Mittwoch, 24. Juni 2020 11:47
> *To:* ORACLE-L (oracle-l_at_freelists.org) <oracle-l_at_freelists.org>
> *Subject:* Re: different plan with insert/select
>
>
>
>
>
> First thoughts:
>
>
>
> What's the source of the references to VW_LAT.... ? In line scalar
> subqueries, existence subqueries, outer joins, or have these lateral views
> appeared from a genuine ANSI lateral() that the optimizer has had to
> transform?
>
>
>
> At first sight it looks like the select statement has been able to do
> something like unnesting one of them to a join while the insert has not
> been allowed to unnest. (So one of those "not quite finished" patterns that
> crops up so frequently at the edges).
>
>
>
> Three other things -
>
> a) Although the plan costs and estimates are vastly different is the work
> similar - is it just an arithmetic error ?
>
> b) Do the two plans get the same results ?
>
> c) There used to be a bug relating to Oracle decorrelating lateral views
> when it shouldn't. Possibly this has been fixed for selects but been
> blocked for insert as select.
>
>
>
>
>
> Regards
>
> Jonathan Lewis
>
>
>
>
>
> On Wed, Jun 24, 2020 at 9:52 AM Noveljic Nenad <
> nenad.noveljic_at_vontobel.com> wrote:
>
> It’s 19.7
>
>
>
> Here’s the plan with select only:
>
>
>
>
> ------------------------------------------------------------------------------------------------------------------------
>
> | Id | Operation | Name |
> Rows | Bytes |TempSpc| Cost (%CPU)| Time |
>
>
> ------------------------------------------------------------------------------------------------------------------------
>
> | 0 | SELECT STATEMENT | |
> 47802 | 30M| | 233K (2)| 00:00:10 |
>
> | 1 | COUNT |
> | | | | | |
>
> | 2 | MERGE JOIN OUTER | |
> 47802 | 30M| | 233K (2)| 00:00:10 |
>
> |* 3 | HASH JOIN RIGHT OUTER | |
> 47802 | 29M| | 42098 (5)| 00:00:02 |
>
> | 4 | TABLE ACCESS FULL | ALL_DIL_BOERSENPLATZ |
> 2348 | 96268 | | 8 (0)| 00:00:01 |
>
> |* 5 | HASH JOIN OUTER | |
> 47802 | 28M| 17M| 42088 (5)| 00:00:02 |
>
> |* 6 | HASH JOIN RIGHT OUTER | |
> 29913 | 17M| 5752K| 16418 (6)| 00:00:01 |
>
> | 7 | TABLE ACCESS FULL | ALL_DIL_GVF |
> 256K| 2750K| | 1424 (4)| 00:00:01 |
>
> |* 8 | HASH JOIN | |
> 29913 | 16M| | 14252 (6)| 00:00:01 |
>
> |* 9 | INDEX RANGE SCAN | PK_ICR_MIT_BOOKKIND |
> 220 | 4400 | | 3 (0)| 00:00:01 |
>
> |* 10 | TABLE ACCESS FULL | ICR_WRK_BEWEGUNG_FKR |
> 110K| 60M| | 14246 (6)| 00:00:01 |
>
> | 11 | VIEW | |
> 5154K| 63M| | 20934 (5)| 00:00:01 |
>
> |* 12 | HASH JOIN RIGHT OUTER | |
> 5154K| 280M| 8656K| 20934 (5)| 00:00:01 |
>
> |* 13 | TABLE ACCESS FULL | ALL_DIL_BEWEGUNG |
> 276K| 5406K| | 5963 (5)| 00:00:01 |
>
> |* 14 | INDEX FAST FULL SCAN | ALL_DIL_STEX_ORDER_LINK_PK |
> 5419K| 191M| | 6341 (6)| 00:00:01 |
>
> | 15 | BUFFER SORT |
> | 1 | 13 | | 233K (2)| 00:00:10 |
>
> | 16 | VIEW | VW_LAT_AEC4E3BF
> | 1 | 13 | | 4 (0)| 00:00:01 |
>
> | 17 | NESTED LOOPS |
> | 1 | 28 | | 4 (0)| 00:00:01 |
>
> | 18 | NESTED LOOPS |
> | 1 | 28 | | 4 (0)| 00:00:01 |
>
> | 19 | TABLE ACCESS BY INDEX ROWID| ALL_DIL_WAEHRUNG_KURS
> | 1 | 14 | | 2 (0)| 00:00:01 |
>
> |* 20 | INDEX RANGE SCAN | PK_ALL_DIL_WAEHRUNG_KURS
> | 1 | | | 1 (0)| 00:00:01 |
>
> |* 21 | INDEX RANGE SCAN | PK_ALL_DIL_WAEHRUNG_KURS
> | 1 | | | 1 (0)| 00:00:01 |
>
> |* 22 | TABLE ACCESS BY INDEX ROWID | ALL_DIL_WAEHRUNG_KURS
> | 1 | 14 | | 2 (0)| 00:00:01 |
>
>
>
>
>
> And with insert:
>
>
>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> | Id | Operation | Name |
> Rows | Bytes |TempSpc| Cost (%CPU)| Time |
>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> | 0 | INSERT STATEMENT |
> | 154G| 92T| | 390M (5)| 04:14:24 |
>
> | 1 | LOAD TABLE CONVENTIONAL | ICR_DAT_BEWEGUNG_FKR
> | | | | | |
>
> | 2 | COUNT |
> | | | | | |
>
> | 3 | MERGE JOIN OUTER |
> | 154G| 92T| | 390M (5)| 04:14:24 |
>
> | 4 | MERGE JOIN OUTER | |
> 29913 | 18M| | 136K (1)| 00:00:06 |
>
> |* 5 | HASH JOIN RIGHT OUTER | |
> 29913 | 18M| | 16427 (6)| 00:00:01 |
>
> | 6 | TABLE ACCESS FULL | ALL_DIL_BOERSENPLATZ
> | 2348 | 96268 | | 8 (0)| 00:00:01 |
>
> |* 7 | HASH JOIN RIGHT OUTER | |
> 29913 | 17M| 5752K| 16418 (6)| 00:00:01 |
>
> | 8 | TABLE ACCESS FULL | ALL_DIL_GVF
> | 256K| 2750K| | 1424 (4)| 00:00:01 |
>
> |* 9 | HASH JOIN | |
> 29913 | 16M| | 14252 (6)| 00:00:01 |
>
> |* 10 | INDEX RANGE SCAN | PK_ICR_MIT_BOOKKIND
> | 220 | 4400 | | 3 (0)| 00:00:01 |
>
> |* 11 | TABLE ACCESS FULL | ICR_WRK_BEWEGUNG_FKR
> | 110K| 60M| | 14246 (6)| 00:00:01 |
>
> | 12 | BUFFER SORT |
> | 1 | 13 | | 136K (1)| 00:00:06 |
>
> | 13 | VIEW | VW_LAT_7AEC37A2
> | 1 | 13 | | 4 (0)| 00:00:01 |
>
> | 14 | NESTED LOOPS |
> | 1 | 28 | | 4 (0)| 00:00:01 |
>
> | 15 | NESTED LOOPS |
> | 1 | 28 | | 4 (0)| 00:00:01 |
>
> | 16 | TABLE ACCESS BY INDEX ROWID| ALL_DIL_WAEHRUNG_KURS
> | 1 | 14 | | 2 (0)| 00:00:01 |
>
> |* 17 | INDEX RANGE SCAN | PK_ALL_DIL_WAEHRUNG_KURS
> | 1 | | | 1 (0)| 00:00:01 |
>
> |* 18 | INDEX RANGE SCAN | PK_ALL_DIL_WAEHRUNG_KURS
> | 1 | | | 1 (0)| 00:00:01 |
>
> |* 19 | TABLE ACCESS BY INDEX ROWID | ALL_DIL_WAEHRUNG_KURS
> | 1 | 14 | | 2 (0)| 00:00:01 |
>
> | 20 | BUFFER SORT |
> | 5154K| | | 390M (5)| 04:14:24 |
>
> | 21 | VIEW | VW_LAT_7AEC37A2
> | 5154K| | | 13058 (5)| 00:00:01 |
>
> |* 22 | FILTER |
> | | | | | |
>
> |* 23 | HASH JOIN RIGHT OUTER |
> | 5154K| 280M| 8656K| 13058 (5)| 00:00:01 |
>
> |* 24 | TABLE ACCESS FULL | ALL_DIL_BEWEGUNG
> | 276K| 5406K| | 5963 (5)| 00:00:01 |
>
> |* 25 | INDEX RANGE SCAN | ALL_DIL_STEX_ORDER_LINK_PK
> | 4410K| 155M| | 3 (0)| 00:00:01 |
>
>
> --------------------------------------------------------------------------------------------------------------------------
>
>
>
> Thanks,
>
>
>
> Nenad
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
> Behalf Of *Jonathan Lewis
> *Sent:* Mittwoch, 24. Juni 2020 10:47
> *To:* ORACLE-L (oracle-l_at_freelists.org) <oracle-l_at_freelists.org>
> *Subject:* Re: different plan with insert/select
>
>
>
>
>
> There's always the distributed query problem.
>
> I've probably got a couple of other cases logged somewhere - will check
> later and follow up
>
>
>
> Which version of Oracle ?
>
>
>
> Regards
>
> Jonathan Lewis
>
>
>
>
>
>
>
> On Wed, Jun 24, 2020 at 8:53 AM Noveljic Nenad <
> nenad.noveljic_at_vontobel.com> wrote:
>
> I’m getting a different execution plan for select if it runs in
> insert/select statement. It’s the same select - embedded in an insert
> statement.
>
>
>
> There are much less join order permutations with insert/select than with
> select. The initial join order 1 is different.
>
>
>
> I’m working on finding out what exactly triggers the different behavior.
> The original statement is rather complex, but I'm working on a simple,
> generic test case.
>
>
>
> Is anybody aware of possible causes?
>
>
>
> Best regards,
>
>
>
> Nenad
>
>
>
> https://nenadnoveljic.com/blog
>
>
>
> ____________________________________________________
>
> Please consider the environment before printing this e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version. Please note that all e-mail communications to and from the
> Vontobel Group are subject to electronic storage and review by Vontobel
> Group. Unless stated to the contrary and without prejudice to any
> contractual agreements between you and Vontobel Group which shall prevail
> in any case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version. Please note that all e-mail communications to and from the
> Vontobel Group are subject to electronic storage and review by Vontobel
> Group. Unless stated to the contrary and without prejudice to any
> contractual agreements between you and Vontobel Group which shall prevail
> in any case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version. Please note that all e-mail communications to and from the
> Vontobel Group are subject to electronic storage and review by Vontobel
> Group. Unless stated to the contrary and without prejudice to any
> contractual agreements between you and Vontobel Group which shall prevail
> in any case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>

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