On Thu, May 31, 2012 at 12:11 PM, Marc L. Allen <mlal...@outsitenetworks.com> wrote: > True, but an optimizer could only intelligently exclude OUTER JOINS in most > cases.
Right, and LEFT OUTER JOINs at that (since SQLite3 doesn't support RIGHT joins). > For instance, if I have a convenience view that combines a series of tables > to provide an overall list of something or another: > > View -> > SELECT ... > FROM a > INNER JOIN b ON ... > INNER JOIN c ON ... > INNER JOIN d ON ... > > As the schema designer, I might know that all three joins will always, ALWAYS > work so that if I use that view and only look at fields in table a, then > don't need those joins. However, since SQLite can't really know that, it > always has to perform all three joins regardless of which fields are returned. Right, because a row from a might not be in the result set given the INNER JOINs. > Also, unless you do rewrite the query, how about this view? "You" here being the application developer / user, of course, not the query optimizer. I should have distinguished INNER and OUTER joins, indeed. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
