Hello,
I have tried indexing a vbulletin message board, containing roughly 7
million posts.
My schema is as follows:
postid
I am trying to figure out if there is anything I can do to lower the disk
usage and or increase sorting speed before we go live wi
Hello,
As mentioned in another post i am trying to index a vbulletin database
containing roughly 7 million posts. The very first query where I apply
sorting after a full indexing, seems to take roughly 264998
ms. Subsequent searches are fast.
I figure the reason is as Chris explained
here(http:/
On Tue, 2006-08-08 at 02:14 -0700, bo_b wrote:
> Is there any solution to this problem? I would like to be able to sort, but
> we cant live with 264 second downtime after every commit.
There has been many long threads in the Lucene-users forum on this
subject. Try searching for "sorting" in subjec
On 8/8/06, bo_b <[EMAIL PROTECTED]> wrote:
As mentioned in another post i am trying to index a vbulletin database
containing roughly 7 million posts. The very first query where I apply
sorting after a full indexing, seems to take roughly 264998
ms. Subsequent searches are fast.
I figure the reas
On 8/8/06, bo_b <[EMAIL PROTECTED]> wrote:
I have tried indexing a vbulletin message board, containing roughly 7
million posts.
My schema is as follows:
postid
I am trying to figure out if there is anything I can do to lower the disk
usage and or increase
Yonik Seeley wrote:
>
> No, they will be roughly the same speed.
> What you *could* try to do is always *index* documents in postid/date
> order... then sorting would not require any FieldCache entry. It
> would require a minor change to Solr (allow sorting on lucene internal
> docid, which mat
