incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David E. Wheeler" <>
Subject Re: [lucy-dev] Who should perform query optimization?
Date Tue, 12 Apr 2011 03:23:49 GMT
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

> 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.



View raw message