On Thu, Sep 14, 2017 at 4:13 PM, Richard Hipp <d...@sqlite.org> wrote:
> On 9/14/17, Darko Volaric <li...@darko.org> wrote: > > I think people are missing the point, probably becuase it's not a great > > example. Consider the following statement: > > > > SELECT funca(slow(10)), funkb(slow(10)) > > > > and lets say slow(10) takes an hour to compute, and funka and funkb take > > almost no time to execute. With common subexpression optimization the > > statement would take one hour, instead of two, to compute because the > value > > of slow(10) would only be calculated once. > > I fully understand the benefits of CSE. My point is that constructs > such as the above are very rarely used in SQLite - so much so that the > amount of extra time spent inside of sqlite3_prepare() in order to > deal with them is not worth the effort. > But why not let the client code decide though? And have it off by default as now? I fully appreciate writing/testing/maintaining that optimisation might be a lot of work, but basing the decision to completely eschew this optimisation on the basis that a non-exhaustive sampling of SQL statements shows it's rarely needed seems a bit "weird" for lack of a better term on my part. Also, when you write that the query time gains are often offset by additional prepare time overhead (and memory as well, as you mentioned) kinda assumes a bad practice of not using (and caching) prepared statements, i.e. the prepare time overhead (1x) could well be worth it for an often-used (prepared/cached) query (Nx, with N large). Not trying to get into the usual "SQLite is lite" arguments here, which given how the NGQP is quite advanced already and not so lite (and holds its own as you wrote against others), I'm just surprised by the rational you're using Richard. Respectfully so. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
