On 11 Apr 2011, at 3:59am, Guilherme wrote: > Well, I thought that if the execution followed a plan.. I could get for > example, the cardinality from the results until a point, say a join. > Imagine a query with 15 joins.. the execution would make a join, than, with > the results from this join, make another join with results form other > joins.. and so on.. I could get the cardinalities before the joins and see > if it is too different from the estimated.. and maybe change the way the > remainder of joins will be executed... > > now, if the execution it's just a nested loop, I can't get any partial > cardinality...
You can tell what it's doing by doing what Igor told you two posts ago: use EXPLAIN and EXPLAIN QUERY PLAN and look at the output. If you read the output of EXPLAIN QUERY PLAN using this page http://www.sqlite.org/eqp.html you will understand what SQLite has chosen to do with your statement. If you read the output of EXPLAIN using the opcodes on this page http://www.sqlite.org/opcode.html you will understand how SQLite decided to implement that. Your underlying task appears to be second-guessing how SQLite's search optimisation works. I have to warn you that the people who wrote it are good at what they do, and they've had 11 years of feedback from real-world use to improve the programming behind it. I'd suggest that you learn how the existing algorithms work in great detail (i.e. read the source code) before trying to improve on what they've done. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
