Keith Medcalf wrote > The primary difference is likely the test on b.c.
/There was some text here that seems to have been lost and my browser opened a "super resume templates" page... maybe I've been already spectre-hacked? Anyway, I repost:/ The primary difference from what I see is that it changes the query plan to start off with an index-based search on b, not a search (scan) on a. To me, this can be due to the supplimentary condition in the ON clause making this plan more appealing to the optimizer. So with this in mind, an easy optimisation would be to just "permeate" any imperative non-null condition in the where clause to the on clause. I don't know if the execution plan is identical to that of an inner join (I never tried to actually convert it to an inner join and I'm working on sth else atm), but it's satisfactory and it starts off the right way, with a search on b, with an execution time well in the expected margins. Keith Medcalf wrote > I think the query is ill-conceived when written as an outer join. If anything, to reflect intentionality the query should have been written as such: SELECT FROM ( SELECT FROM a LEFT JOIN b ) WHERE b.c=5 -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
