On Mar 26, 2004, at 2:20 AM, Morus Walter wrote:
Erik Hatcher writes:
Why not do the unique sequential number replacement at index time
rather than query time?
how would you do that? This requires to know the ids that will be added
in future.
Let's say you start with strings 'a' and 'b'. Later you
Erik Hatcher wrote:
On Mar 26, 2004, at 2:20 AM, Morus Walter wrote:
Erik Hatcher writes:
Why not do the unique sequential number replacement at index time
rather than query time?
how would you do that? This requires to know the ids that will be added
in future.
Let's say you start with strings
You could form your results into XML and do a simple XSL
transformation to get what you want.
Cool! What's the name of the XSLT processor you are using that can sort
1M records in memory?
-
To unsubscribe, e-mail: [EMAIL
Robert Koberg wrote:
Eric Jain wrote:
You could form your results into XML and do a simple XSL
transformation to get what you want.
Cool! What's the name of the XSLT processor you are using that can sort
1M records in memory?
jd.xslt is known to handle extremely large sources:
Do your search queries really result in 1MB of results? Is that a huge
number of hits or are your fields extremely large?
The fields are not more than a dozen characters long, but there can
easily be several hundred thousand hits. Of course usually only the top
N hits need to be displayed, but
You can see the resolution in the latest CVS ;-)
Just to clarify things: Does the current solution require all fields
that can be used for sorting to be loaded and kept in memory? (I guess
you can answer this question faster than I can figure it out by myself
:-)
Eric Jain wrote:
Just to clarify things: Does the current solution require all fields
that can be used for sorting to be loaded and kept in memory? (I guess
you can answer this question faster than I can figure it out by myself
:-)
Field values are loaded into memory. But values are kept in an
Eric Jain wrote:
That's reasonable. What I didn't quite understand yet: If I sort on a
string field, will Lucene need to keep all values in memory all the
time, or only during startup?
It will cache one instance of each unique value. So if you have a
million documents and string sort results on
But if the field has 1M different values, then
the array will hold 1M unique strings.
The strings according to which I need to sort are unique identifiers :-(
I will need to have a look at the code, but I assume that in principal
it should be possible to replace the strings with sequential
Eric Jain wrote:
I will need to have a look at the code, but I assume that in principal
it should be possible to replace the strings with sequential integers
once the sorting is done?
I don't understand the question.
Doug
-
To
I will need to have a look at the code, but I assume that in
principal it should be possible to replace the strings with
sequential integers once the sorting is done?
I don't understand the question.
I need to: Sort by a field containing 1M distinct strings. While I can't
afford to waste
Why not do the unique sequential number replacement at index time
rather than query time?
Erik
On Mar 25, 2004, at 6:26 PM, Eric Jain wrote:
I will need to have a look at the code, but I assume that in
principal it should be possible to replace the strings with
sequential integers once the
Erik Hatcher writes:
Why not do the unique sequential number replacement at index time
rather than query time?
how would you do that? This requires to know the ids that will be added
in future.
Let's say you start with strings 'a' and 'b'. Later you add a document
with 'aa'. How do you know
Was there any conclusion to message:
http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=6762
Regarding Ordering by a Field? I have a similar need and didn't see the resolusion
in that thread. Is it a current patch to the 1.3-final, I could see one?
My other option, I guess, is
Chad,
Was there any conclusion to message:
http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=6762
Regarding Ordering by a Field? I have a similar need and didn't see the
resolusion in that thread. Is it a current patch to the 1.3-final, I could
see one?
You can see the resolution
15 matches
Mail list logo