Lennart Regebro wrote at 2007-3-28 18:25 +0200:
On 3/27/07, Dieter Maurer [EMAIL PROTECTED] wrote:
However, this approach is only efficient when the sort index size
is small compared to the result size.
Sure. But with incremental searching, the result size is always one, right? ;-)
No. You
Jim Fulton wrote at 2007-3-26 15:55 -0400:
...
On Mar 26, 2007, at 3:28 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2007-3-25 09:53 -0400:
On Mar 25, 2007, at 3:01 AM, Adam Groszer wrote:
MF I think one of the main limitations of the current catalog (and
MF hurry.query) is efficient
On Mar 26, 2007, at 3:28 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2007-3-25 09:53 -0400:
On Mar 25, 2007, at 3:01 AM, Adam Groszer wrote:
MF I think one of the main limitations of the current catalog (and
MF hurry.query) is efficient support for sorting and batching the
query
MF
On Mar 25, 2007, at 3:01 AM, Adam Groszer wrote:
MF I think one of the main limitations of the current catalog (and
MF hurry.query) is efficient support for sorting and batching the
query
MF results. The Zope 3 catalog returns all matching results, which
can then
MF be sorted and batched.
On Mar 25, 2007, at 11:08 AM, Lennart Regebro wrote:
...
2. Use an N-best algorithm. If N is the size of the batch and M is
the corpus size, then this is O(M*ln(N)) rather than O(M*ln(M)) which
is a significant improvement if N M, but still quite expensive.
I don't think relational databases