[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739922#action_12739922 ] Uwe Schindler commented on LUCENE-1769: --- I will look into this later. Thanks for the

[jira] Updated: (LUCENE-1607) String.intern() faster alternative

[ https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1607: -- Attachment: LUCENE-1607-contrib.patch I found one real occurrence of intern() in crontrib and

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739894#action_12739894 ] Robert Muir commented on LUCENE-1771: - it looks like it is downloading files due to li

[jira] Issue Comment Edited: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739885#action_12739885 ] Mark Miller edited comment on LUCENE-1771 at 8/5/09 7:44 PM: -

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739885#action_12739885 ] Mark Miller commented on LUCENE-1771: - Well nevermind - no auto commit in either of th

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739859#action_12739859 ] Nick Pellow commented on LUCENE-1769: - When this is integrated and committed to svn, s

[jira] Issue Comment Edited: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739844#action_12739844 ] Luis Alves edited comment on LUCENE-1782 at 8/5/09 6:26 PM: Hi

[jira] Issue Comment Edited: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739844#action_12739844 ] Luis Alves edited comment on LUCENE-1782 at 8/5/09 6:13 PM: Hi

[jira] Issue Comment Edited: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739838#action_12739838 ] Luis Alves edited comment on LUCENE-1782 at 8/5/09 6:13 PM: {q

[jira] Created: (LUCENE-1785) Simple FieldCache merging

Simple FieldCache merging - Key: LUCENE-1785 URL: https://issues.apache.org/jira/browse/LUCENE-1785 Project: Lucene - Java Issue Type: Improvement Components: Search Affects Versions: 2.4.1 R

[jira] Issue Comment Edited: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739844#action_12739844 ] Luis Alves edited comment on LUCENE-1782 at 8/5/09 6:12 PM: Hi

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739854#action_12739854 ] Nick Pellow commented on LUCENE-1769: - I've provided a download of the jar, just for y

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739855#action_12739855 ] Luis Alves commented on LUCENE-1782: Hi Mike, I think I forgot to add a readme.txt to

[jira] Updated: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-1771: Attachment: LUCENE-1771.patch Here it is basically. Core tests pass, but oddly TestCompoundWordTo

[jira] Issue Comment Edited: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739851#action_12739851 ] Luis Alves edited comment on LUCENE-1782 at 8/5/09 6:02 PM: To

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739851#action_12739851 ] Luis Alves commented on LUCENE-1782: To build the OriginalQueryParser. Delete - Ori

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739844#action_12739844 ] Luis Alves commented on LUCENE-1782: Hi, I'm adding another example to try to describ

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739842#action_12739842 ] Nick Pellow commented on LUCENE-1769: - Hi Uwe, Clover will still produce code covera

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739840#action_12739840 ] Luis Alves commented on LUCENE-1782: I also want to point to everyone, that we should

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739838#action_12739838 ] Luis Alves commented on LUCENE-1782: {quote} renamed StandardQueryParserHelper to simp

[jira] Commented: (LUCENE-1685) Make the Highlighter use SpanScorer by default

[ https://issues.apache.org/jira/browse/LUCENE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739833#action_12739833 ] Michael McCandless commented on LUCENE-1685: Should we also default the fragme

[jira] Commented: (LUCENE-1486) Wildcards, ORs etc inside Phrase queries

[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739826#action_12739826 ] Mark Miller commented on LUCENE-1486: - The plan is to remove it and add a replacement

[jira] Reopened: (LUCENE-1486) Wildcards, ORs etc inside Phrase queries

[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reopened LUCENE-1486: Reopening so we don't forget to do this one... Come 3.0, how will this work, even in

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739817#action_12739817 ] Michael McCandless commented on LUCENE-1782: I plan to commit this in the next

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739785#action_12739785 ] Michael McCandless commented on LUCENE-1771: bq. why not just make QueryWeight

Re: Attributes, DocConsumer, Flexible Indexing, etc.

So basically you could build all of this out on top of the existing payloads extensibility? It sounds promising! LUCENE-1458 also enables neat low-level index format changes like pulsing (rare terms inline their postings directly into the terms dict, which saves 2 seeks) and [eventually] PForDelt

Re: Attributes, DocConsumer, Flexible Indexing, etc.

On Aug 5, 2009, at 4:35 PM, Michael Busch wrote: On 8/5/09 1:07 PM, Grant Ingersoll wrote: Hmmm, OK. Random, somewhat uneducated thought: Why not just define the codecs to create byte arrays? Then we can use the existing payload capability much like I do with the DelimitedPayloadTokenFi

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739779#action_12739779 ] Mark Miller commented on LUCENE-1771: - That was my first consideration - but then I th

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739776#action_12739776 ] Michael McCandless commented on LUCENE-1771: Hmm, Weight is an interface, whic

Re: benchmark: lucene24 vs lucene29

On Wed, Aug 5, 2009 at 5:07 PM, Mark Miller wrote: > It is autocommit. Changing it to false for 2.4 brings it down to one minute > slower than 2.9. > > When its on, wa is 20-30% and the cpu just barley moves. When its off, its a > similar profile to 2.9. > > Theres a speed trap :) > > I'm on ext4.

Refactor TokenStream implementations to receive configuration from AttributeSource

Hi, The AttributeSource/Attribute API was recently added to Lucene, it allows a dynamic communication between TokenStream with better performance, avoiding unnecessary object creation and unnecessary casting. The new query parser framework takes advantage of this new feature using Attributes to se

Re: benchmark: lucene24 vs lucene29

On Wed, Aug 5, 2009 at 5:07 PM, Mark Miller wrote: > It is autocommit. Changing it to false for 2.4 brings it down to one minute > slower than 2.9. > > When its on, wa is 20-30% and the cpu just barley moves. When its off, its a > similar profile to 2.9. > > Theres a speed trap :) > > I'm on ext4.

Re: benchmark: lucene24 vs lucene29

Yonik Seeley wrote: On Wed, Aug 5, 2009 at 4:35 PM, Michael McCandless wrote: Hmm -- looks like 2.9 defaulted to autoCommit=false, but that can't explain such a big difference. It perhaps could in conjunction with file synchronization on commit... and some filesystems being bad at fsyn

Re: benchmark: lucene24 vs lucene29

On Wed, Aug 5, 2009 at 4:35 PM, Michael McCandless wrote: > Hmm -- looks like 2.9 defaulted to autoCommit=false, but that can't > explain such a big difference. It perhaps could in conjunction with file synchronization on commit... and some filesystems being bad at fsync() (like ext3 which sync's

[jira] Commented: (LUCENE-1749) FieldCache introspection API

[ https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739743#action_12739743 ] Mark Miller commented on LUCENE-1749: - patch is coming soon - I've merged to trunk and

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739741#action_12739741 ] Mark Miller commented on LUCENE-1771: - But it would imply that we merge QueryWeight ba

Re: benchmark: lucene24 vs lucene29

Can you run the 2.4 benchmark code against a 2.9 jar? Not sure if this can be done, but we can at least detect where's the change coming from. On Wed, Aug 5, 2009 at 11:43 PM, Mark Miller wrote: > Its the indexing it appears. Its very weird. > > With 2.4, during index, CPU keeps dropping to almo

Re: benchmark: lucene24 vs lucene29

Its the indexing it appears. Its very weird. With 2.4, during index, CPU keeps dropping to almost 0, and wa hits 20-30% for long stretches. Not much CPU is being used. With 2.9, wa stays under 1% and CPU is pretty much always 100-300%. - Mark Shai Erera wrote: Does it measure only indexing,

[jira] Updated: (LUCENE-1341) BoostingNearQuery class (prototype)

[ https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated LUCENE-1341: Attachment: LUCENE-1341.patch Minor mods and some javadocs. Looks pretty good. I made su

Re: benchmark: lucene24 vs lucene29

Does it measure only indexing, or search as well? I think 2.9 does have some good improvements to the search side, especially for sorting. Maybe it's not "one big thing" that's causing this improvement, but rather the aggregation of several "smaller things"? On Wed, Aug 5, 2009 at 11:35 PM, Micha

Re: benchmark: lucene24 vs lucene29

Hmm -- looks like 2.9 defaulted to autoCommit=false, but that can't explain such a big difference. Mike On Wed, Aug 5, 2009 at 4:19 PM, Mark Miller wrote: > Michael McCandless wrote: >> >> Was the resulting index size approximately the same? >> >> > > lucene 2.9 > > total 24480 > -rw-r--r-- 1 mar

Re: Attributes, DocConsumer, Flexible Indexing, etc.

On 8/5/09 1:07 PM, Grant Ingersoll wrote: Hmmm, OK. Random, somewhat uneducated thought: Why not just define the codecs to create byte arrays? Then we can use the existing payload capability much like I do with the DelimitedPayloadTokenFilter. We'd probably have to make sure this still wo

[jira] Updated: (LUCENE-1341) BoostingNearQuery class (prototype)

[ https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated LUCENE-1341: Fix Version/s: (was: 3.0) 2.9 > BoostingNearQuery class (prototype)

Re: benchmark: lucene24 vs lucene29

Michael McCandless wrote: Was the resulting index size approximately the same? lucene 2.9 total 24480 -rw-r--r-- 1 mark mark 18548115 2009-08-05 15:46 _0.fdt -rw-r--r-- 1 mark mark 160004 2009-08-05 15:46 _0.fdx -rw-r--r-- 1 mark mark 47 2009-08-05 15:46 _5m.fnm -rw-r--r-- 1 mark ma

Re: Attributes, DocConsumer, Flexible Indexing, etc.

On Aug 5, 2009, at 3:27 PM, Michael Busch wrote: I think we're not quite there yet, where you can create a custom indexing format easily and store your custom Attributes. What's especially missing is an API on the retrieval side, on a TermDocs/ TermPositions level, that can read custom inde

Re: benchmark: lucene24 vs lucene29

Hmmm ... its not less RAM - its 140 for both. I'll share my results when its done, and double check that I'm not missing anything - but its two fresh checkouts and identical conditions that I can see. 2.9 took a little over 3 minutes. 2.4 took - well, I'll tell you when its done, but its alr

Re: benchmark: lucene24 vs lucene29

We didn't spend much effort speeding up indexing, I think? Was OS's IO cache warm for both of your tests? Was the resulting index size approximately the same? Mike On Wed, Aug 5, 2009 at 4:00 PM, Mark Miller wrote: > Has anything changed in benchmark that would make things uncomparable > betwee

Re: benchmark: lucene24 vs lucene29

Well .. the latest additions reuse a Document instance and Fields by default. Don't think it should make that much of a difference though. On Wed, Aug 5, 2009 at 11:00 PM, Mark Miller wrote: > Has anything changed in benchmark that would make things uncomparable > between 2.9 and 2.4? > > I don'

Re: benchmark: lucene24 vs lucene29

Mark Miller wrote: Has anything changed in benchmark that would make things uncomparable between 2.9 and 2.4? I don't see anything in Changes that should have that much of an affect ... I tried micro bench on each and 2.9 ran twice as fast. I also tried standard. Which is a crazy difference

benchmark: lucene24 vs lucene29

Has anything changed in benchmark that would make things uncomparable between 2.9 and 2.4? I don't see anything in Changes that should have that much of an affect ... I tried micro bench on each and 2.9 ran twice as fast. I also tried standard. Which is a crazy difference. Particularly, with

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739703#action_12739703 ] Adriano Crestani commented on LUCENE-1782: -- Thanks Mike :) {quote} The patch als

[jira] Updated: (LUCENE-1341) BoostingNearQuery class (prototype)

[ https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Keegan updated LUCENE-1341: - Attachment: lucene-1341-new-2.patch New version that works with current trunk (8/5/09) > Boosti

Re: Attributes, DocConsumer, Flexible Indexing, etc.

I think we're not quite there yet, where you can create a custom indexing format easily and store your custom Attributes. What's especially missing is an API on the retrieval side, on a TermDocs/TermPositions level, that can read custom indexing formats. We also need to make the SegmentMerger m

[jira] Updated: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1782: --- Attachment: LUCENE-1782.patch Attached enormous patch. It's much simpler than it lo

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739671#action_12739671 ] Michael McCandless commented on LUCENE-1782: bq. Give it a try and let me know

Re: SpanQuery and BoostingTermQuery oddities

If we end up keeping Weight, I don't think the Changes entry on back compat says enough? If you overrode protected Weight createWeight(Query query) throws IOException, its not called anymore so you are dead in the water? And just overall, it appears to be a break, but the instructions don't t

[jira] Resolved: (LUCENE-1758) improve arabic analyzer: light8 -> light10

[ https://issues.apache.org/jira/browse/LUCENE-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-1758. - Resolution: Fixed committed revision 801348. > improve arabic analyzer: light8 -> light10 > ---

Re: SpanQuery and BoostingTermQuery oddities

This is a little different than what Grant was talking about. For the old variants to work, I think you have to call the Searcher methods that take an old style weight. Its not an ideal break, I know. I think we might consider just dropping Weight? If we make the issue with 1771 a compile tim

Attributes, DocConsumer, Flexible Indexing, etc.

I've been trying out the new Attribute stuff and still am a bit stumped as to where all of this stuff gets us. I can create Attributes and AttributeSources to my heart's content, but don't see an obvious path towards actually getting them in the index. I gather it has something to do with

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739656#action_12739656 ] Adriano Crestani commented on LUCENE-1782: -- Hi Mike, I think ParseException is t

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739653#action_12739653 ] Michael McCandless commented on LUCENE-1782: OK I have a huge patch working, b

[jira] Resolved: (LUCENE-1607) String.intern() faster alternative

[ https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved LUCENE-1607. -- Resolution: Fixed committed. > String.intern() faster alternative > -

Re: SpanQuery and BoostingTermQuery oddities

I got it to work by adding new overrides: public QueryWeight createQueryWeight(Searcher searcher) throws IOException public Scorer scorer(IndexReader reader, boolean scoreDocsInOrder, boolean topScorer) throws IOException But, it seems like it should still work with the old overrides: prote

Re: Java caching of low-level index data?

Hi Mike, This is a very belated reply, but I just wanted to say that I really appreciate your comments -- this has been a very helpful and informative discussion! (-: Thanks, Chris On Thu, Jul 23, 2009 at 10:50 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Thu, Jul 23, 2009 a

[jira] Commented: (LUCENE-1607) String.intern() faster alternative

[ https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739628#action_12739628 ] Yonik Seeley commented on LUCENE-1607: -- bq. Except I'd like the javadoc demand each i

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739618#action_12739618 ] Michael Busch commented on LUCENE-1782: --- Thanks, Mike. This sounds good. > Rename O

[jira] Created: (LUCENE-1784) Make BooleanWeight and DisjunctionMaxWeight protected

Make BooleanWeight and DisjunctionMaxWeight protected - Key: LUCENE-1784 URL: https://issues.apache.org/jira/browse/LUCENE-1784 Project: Lucene - Java Issue Type: Improvement Affects Ve

Re: SpanQuery and BoostingTermQuery oddities

I ran into the same problem trying to update the BoostingNearQuery patch in *LUCENE-1341 . *The scorer never gets called. This used to work in 2.3.2 Peter On Wed, Aug 5, 2009 at 11:01 AM, Mark Miller wrote: > Grant Ingersoll wrote: > >> >> On A

Re: Java caching of low-level index data?

Thanks, that's good feedback! Chris On Mon, Aug 3, 2009 at 8:50 AM, Earwin Burrfoot wrote: > > I'm curious if anyone has thought about (or even tried) caching the > low-level index data in Java, rather than > > in the OS. For example, at the IndexInput level there could be an LRU > cache of by

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739561#action_12739561 ] Michael McCandless commented on LUCENE-1771: bq. But shouldn't we just make it

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739550#action_12739550 ] Mark Miller commented on LUCENE-1771: - bq. I think a hard break is better than a subtl

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739547#action_12739547 ] Michael McCandless commented on LUCENE-1771: bq. And break back compat?! Yeah,

Re: SpanQuery and BoostingTermQuery oddities

Grant Ingersoll wrote: On Aug 5, 2009, at 10:07 AM, Mark Miller wrote: Yeah - SpanQuery's don't use the boosts from subspans - it just uses the idf for the query terms and the span length I believe - and the boost for the top level Query. Is that the right way to go? I guess Doug seemed to t

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739541#action_12739541 ] Mark Miller commented on LUCENE-1771: - bq. Hmm... shouldn't explain take the top-level

[jira] Commented: (LUCENE-1782) Rename OriginalQueryParserHelper

[ https://issues.apache.org/jira/browse/LUCENE-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739531#action_12739531 ] Michael McCandless commented on LUCENE-1782: OK I'll work up a patch, renaming

Re: SpanQuery and BoostingTermQuery oddities

On Aug 5, 2009, at 10:07 AM, Mark Miller wrote: Yeah - SpanQuery's don't use the boosts from subspans - it just uses the idf for the query terms and the span length I believe - and the boost for the top level Query. Is that the right way to go? I guess Doug seemed to think so? I don't kno

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739529#action_12739529 ] Michael McCandless commented on LUCENE-1771: Hmm... shouldn't explain take the

Re: SpanQuery and BoostingTermQuery oddities

Grant Ingersoll wrote: A BoostingTermQuery (BTQ) is a SpanQuery. If I run: IndexSearcher searcher = new IndexSearcher(dir, true); searcher.setSimilarity(payloadSimilarity);//set the similarity. Very important BoostingTermQuery btq = new BoostingTermQuery(new Term("body", "fox"));

SpanQuery and BoostingTermQuery oddities

A BoostingTermQuery (BTQ) is a SpanQuery. If I run: IndexSearcher searcher = new IndexSearcher(dir, true); searcher.setSimilarity(payloadSimilarity);//set the similarity. Very important BoostingTermQuery btq = new BoostingTermQuery(new Term("body", "fox")); TopDocs topDocs =

[jira] Resolved: (LUCENE-1685) Make the Highlighter use SpanScorer by default

[ https://issues.apache.org/jira/browse/LUCENE-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved LUCENE-1685. - Resolution: Fixed > Make the Highlighter use SpanScorer by default > ---

[jira] Resolved: (LUCENE-1783) Benchmark highlights with older QueryTermScorer rather than the default QueryScorer.

[ https://issues.apache.org/jira/browse/LUCENE-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved LUCENE-1783. - Resolution: Invalid I swear I had changed benchmark to use QueryTermScorer as part of LUCENE-168

[jira] Resolved: (LUCENE-1779) Remove unused "numSlotsFull" from FieldComparator.setNextReader

[ https://issues.apache.org/jira/browse/LUCENE-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1779. Resolution: Fixed > Remove unused "numSlotsFull" from FieldComparator.setNextReade

[jira] Commented: (LUCENE-1341) BoostingNearQuery class (prototype)

[ https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739464#action_12739464 ] Grant Ingersoll commented on LUCENE-1341: - Peter, can you bring this up to date?

[jira] Resolved: (LUCENE-1773) Add benchmark task for FastVectorHighlighter

[ https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1773. Resolution: Fixed Trying again :) > Add benchmark task for FastVectorHighlighter

[jira] Issue Comment Edited: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739423#action_12739423 ] Uwe Schindler edited comment on LUCENE-1769 at 8/5/09 4:26 AM: -

Re: contrib CHANGES and contrib/benchmark CHANGES

to me, it might make the most sense to add a "Benchmark" section to the contrib/CHANGES for each release. this still keeps things organized nicely, but in the same text file at least? On Wed, Aug 5, 2009 at 5:05 AM, Michael McCandless wrote: > On Tue, Aug 4, 2009 at 6:38 PM, Robert Muir wrote: >>

[jira] Issue Comment Edited: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739423#action_12739423 ] Uwe Schindler edited comment on LUCENE-1769 at 8/5/09 3:46 AM: -

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739423#action_12739423 ] Uwe Schindler commented on LUCENE-1769: --- Hi Nick, I will look into this at the end

[jira] Commented: (LUCENE-1773) Add benchmark task for FastVectorHighlighter

[ https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739407#action_12739407 ] Michael McCandless commented on LUCENE-1773: Sigh. I had wrongly committed th

Re: Hudson Build failed

I think this was a latent bug (contrib/benchmark's build.xml doesn't express the dependency it has on contrib/memory, because it's using contrib/highlighter), uncovered by my commits for LUCENE-1773. I'll add a contrib/memory dependency into contrib/benchmark's build.xml under LUCENE-1773. Mike

[jira] Commented: (LUCENE-1773) Add benchmark task for FastVectorHighlighter

[ https://issues.apache.org/jira/browse/LUCENE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739391#action_12739391 ] Michael McCandless commented on LUCENE-1773: Indeed, the CountingHighlighterTe

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739388#action_12739388 ] Nick Pellow commented on LUCENE-1769: - bq. we have some "untested" code parts (because

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739384#action_12739384 ] Michael McCandless commented on LUCENE-1771: {quote} bq. I'm confused... why i

Re: contrib CHANGES and contrib/benchmark CHANGES

On Tue, Aug 4, 2009 at 6:38 PM, Robert Muir wrote: > curious how people feel about folding the contrib/benchmark CHANGES > into the contrib CHANGES? +1 Mike - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For ad

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739380#action_12739380 ] Nick Pellow commented on LUCENE-1769: - Hi Uwe, Thanks for confirming that error. It w

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739379#action_12739379 ] Uwe Schindler commented on LUCENE-1769: --- Hi Nick, I have another question about the

[jira] Commented: (LUCENE-1769) Fix wrong clover analysis because of backwards-tests, upgrade clover to 2.4.3 or better

[ https://issues.apache.org/jira/browse/LUCENE-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739375#action_12739375 ] Uwe Schindler commented on LUCENE-1769: --- > Hi Uwe, > I noticed that in your patch to

Hudson Build failed

Hi, The Hudson build failed last night with the following error: [junit] Testcase: testHighlighting(org.apache.lucene.benchmark.byTask.TestPerfTasksLogic): Caused an ERROR [junit] org/apache/lucene/index/memory/MemoryIndex [junit] java.lang.NoClassDefFoundError: org/apache/lucene/