Re: Optimizer and ANSI Joins

  • From: Jared Still <jkstill@xxxxxxxxx>
  • To: Sayan Malakshinov <xt.and.r@xxxxxxxxx>
  • Date: Tue, 29 Jan 2019 09:55:21 -0800

Interesting, thank you Sayan.

I had not previously seen that function, at least not that I can remember.

Nonetheless, there is usually some kernel of truth behind rumors such as
this, and I am curious as to what that is.


Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Principal Consultant at Pythian
Pythian Blog http://www.pythian.com/blog/author/still/
Github: https://github.com/jkstill




On Tue, Jan 29, 2019 at 9:50 AM Sayan Malakshinov <xt.and.r@xxxxxxxxx>
wrote:

Hi Jared,

Of course, cbo understand ansi joins, because it transforms them into own
syntax :)
(with some nuances like full outer join(it has now native full outer join,
but not in syntax yet) or outer join to more than one table before 12c)

You can check 10053 trace or dbms_sql2.expand_sql_text
(DBMS_UTILITY.expand_sql_text since 12c)

вт, 29 янв. 2019 г., 20:10 Jared Still jkstill@xxxxxxxxx:

Hello All:

Something I have heard a few times is that the Oracle Optimizer does not
understand ANSI joins, and that ANSI joins are first converted to some
legacy format before the optimizer processes them.

Does anyone here know if there is any truth in this?

Some things that come to mind:

- perhaps it was true at one time (9i)
- only partially true
- a blatant lie started by a SQL Server Fan.

OK, that last one was uncalled for, but a little humor is necessary
sometimes :)

I have googled around for this a bit, but find nothing that really
discusses the topic.

Thanks,

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Principal Consultant at Pythian
Pythian Blog http://www.pythian.com/blog/author/still/
Github: https://github.com/jkstill



Other related posts: