On Wednesday, May 30, 2012 10:02:24 f.h. Igor Tandetnik wrote: > On 5/29/2012 8:21 PM, Charles Samuels wrote: > > Suppose you have a query like this: > > > > select Employee.name from Employees left join Uniform on > > > > (EmployeeSize.name=Uniform.employeeName) > > Doesn't look like a valid query to me. What's Employee and EmployeeSize? > I assume you meant Employees in both places. EmployeeSize should mean "Employee". I seem to never be able to proofread an email enough.
> > > This query's result should be identical weather or not we have that join; > > it's an outer join, not an inner join, afterall. However, explain query > > plan (and my time measurements) seem to indicate that the the query with > > the join is far slower/more complex. > > > > Is it hypothetically possible that the optimizer could avoid the join? > > In principle, yes. > > > Is there a way to get sqlite to do so? > > Sure. Remove the join from the query. That's not a helpful answer because I can't know to do so without parsing the SQL myself. > > > Is this a planned feature? > > Well, it's not a feature, it's a lack thereof. The query planner is not > specifically looking for this particular optimization opportunity - > probably because such situations are uncommon and are not worth the time > looking for. Your question seems to suggest that optimizations magically > happen by themselves unless someone specifically writes code to block > them; in reality, it's the other way round. "A planned feature" refers to a feature that does not yet exist. I am asking if sqlite will ever be able to do this optimization? cs _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
