On Apr 11, 2011, at 4:32 PM, Marvin Humphrey wrote: > On Sun, Apr 10, 2011 at 12:08:05PM -0700, Nathan Kurz wrote: >> Query optimization is a great thing, but it should not happen behind the >> scenes. > > That's a really interesting perspective.
One I disagree with, personally. > We would expect something like psql, the command-line interface to PostgreSQL, > to perform implicit query optimization "behind the scenes" when an end-user > supplies a query as SQL text. We would likewise expect a search engine app > based on Lucy to perform implicit query optimization when an end-user supplies > a text query string. psql doesn't do that. The server back end does it. The front-end just passes the queries to the back end. From KinoSearch's perspective, you should pretend there is no psql, just DBD::Pg (or libpq). > So what we're talking about here instead is Lucy's programmatic, OO interface. > Several Searcher methods accept a Query object as an argument. Should > Searcher perform query optimization internally, or should it assume that the > Query has been fully optimized already? > > Put another way: Should query optimization be the domain of the application, > or the library? The library. See http://oreilly.com/catalog/9780596523084/ > To disable optimization, or enact custom optimizations, the user needs to > implement custom Compiler classes. (For now, that means they must also > implement custom Query classes, since Queries serve as factories for > Compilers.) > > Honestly, I doubt that many users will seek to exert manual control over query > optimization -- but if they want to, they can. Nice that it's there, but it should be damn near impossible for a user to optimize a query better than the core does, IMHO. Best, David
