Hello,
I think the link from Cory show in what relation this come in to play ?
The transformation retains the original join order of authors, titleauthor, and titles. In this example, the scan of titles has two searchable arguments on it—ta.title_id = t.title_id and a.au_id = t.title_id. So, the scan of titles fails because of the searchable argument value established by the scan of titleauthor, or it fails because of the searchable argument value established by the scan of authors. If no rows are returned from a scan of titles because of the searchable argument value set by the scan of authors, there is no point in continuing the scan of titleauthor. For every row fetched from titleauthor, the scan of titles fails. It is only when a new row is fetched from authors that the scan of titles might succeed. This is why NARY NESTED LOOP JOINs have been implemented; they eliminate the useless draining of tables that have no impact on the rows returned by successive scans.
In the example, the NARY NESTED LOOP JOIN operator closes the scan of titleauthor, fetches a new row from authors, and repositions the scan of titleauthor based on the au_id fetched from authors. Again, this can be a significant performance improvement as it eliminates the needless draining of the titleauthor table and the associated I/O that could occur.
The order of the does not matter only the relation between them.
Niclas