Re: bytecount as String and prefix length

On Nov 1, 2005, at 9:51 AM, Doug Cutting wrote: Another approach might be to, instead of converting to UTF-8 to strings right away, change things to convert lazily, if at all. During index merging such conversion should never be needed. !! There ought to be some gains possible there, then.

Re: bytecount as String and prefix length

Thanks for looking into this Marvin... very interesting stuff! I haven't had a chance to review it in detail, but my gut tells me that it should be able to be faster. -Yonik Now hiring -- http://forms.cnet.com/slink?231706 - To u

[jira] Commented: (LUCENE-395) CoordConstrainedBooleanQuery + QueryParser support

[ http://issues.apache.org/jira/browse/LUCENE-395?page=comments#action_12356538 ] paul.elschot commented on LUCENE-395: - Another way would be to override getBooleanQuery in QueryParser and check there whether one of the given clauses has a special form,

[jira] Commented: (LUCENE-395) CoordConstrainedBooleanQuery + QueryParser support

[ http://issues.apache.org/jira/browse/LUCENE-395?page=comments#action_12356528 ] Hoss Man commented on LUCENE-395: - To recap: * The orriginal bug proposed a new Query class, and provided a sample query parser that leveraged it. * subsequent discussions

Re: bytecount as String and prefix length

Another approach might be to, instead of converting to UTF-8 to strings right away, change things to convert lazily, if at all. During index merging such conversion should never be needed. You needn't do this systematically throughout Lucene, but only where it makes a big difference. For exa

RE: Faking index merge by modifying segments file?

The solution we came up with is (I think) a bit better, since it does require any copying of files. Since MultiSegmentReader already does the segment/document # offsetting, and a segment does not change after written, we created a reopen() method that reopens an existing index, (knowing which segm

Re: bytecount as String and prefix length

Marvin Humphrey wrote: I think it's time to throw in the towel. Please don't give up. I think you're quite close. I would be careful using CharBuffer instead of char[] unless you're sure all methods you call are very efficient. You could try avoiding CharBuffer by adding something (ugly) l

RE: Faking index merge by modifying segments file?

Hello Otis, I worked on a similar issue a couple on months ago. I've included our email conversation below. Hopefully, your thread will prompt more interest from the mailing list. -Kevin Sort of -- but only within a very controlled situation along with some hackery you can comment out both

RE: Faking index merge by modifying segments file?

Problem is the terms need to be sorted in a single segment. -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 1:52 AM To: java-dev@lucene.apache.org Subject: Faking index merge by modifying segments file? Hello, I spent most of today ta

Re: bytecount as String and prefix length

I wrote: I've got one more idea... time to try overriding readString and writeString in BufferedIndexInput and BufferedIndexOutput, to take advantage of buffers that are already there. Too complicated to be worthwhile, it turns out. I think it's time to throw in the towel. Frustrating,

Re: Faking index merge by modifying segments file?

On Tuesday 01 November 2005 08:51, Otis Gospodnetic wrote: > Hello, > > I spent most of today talking to some people about Lucene, and one of > them said how they would really like to have an "instantaneous index > merge", and how he is thinking he could achieve that by simply opening > segments f