Lennart Regebro wrote at 2007-3-25 17:08 +0200:
>> 1. Sort your results based on the "primary key" and therefore, pick
>> your primary key to match your sort results. In terms of the Zope
>> catalog framework, the primary keys are the document IDs, which are
>> traditionally chosen randomly. You can pick your primary keys based
>> on a desired sort order instead. A variation on this theme is to use
>> multiple sets of document ids, storing multiple sets of ids in each
>> index. Of course, this approach doesn't help with something like
>> relevance ranks.
>I don't know if relational databases typically does this internally (I
>don't think so). However, some search engines do it, like Lucene. And
>supposedly also Dieters IncrementalSearch (haven't used it yet).
When "IncrementalSearch" does it, it works roughly as Jim described it
under 1 above (although there is no need that it works the the "primary
Unless the indexes are able to return sorted (partial results), we
need to determine the results first and then sort them. And that
takes time at least linear in the number of hits (to determine the sort
values for the documents).
Zope3-dev mailing list