[jira] Created: (LUCENE-2018) Reconsider boolean max clause exception

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
Reconsider boolean max clause exception
---------------------------------------

                 Key: LUCENE-2018
                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
             Project: Lucene - Java
          Issue Type: Improvement
            Reporter: Mark Miller


Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens it because a user built the boolean themselves. And no duh thousands more boolean queries means slower perf and more resources needed. When don't throw an exception when you try in use a ton of resources in a thousand other ways.

The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.

I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated LUCENE-2018:
--------------------------------

    Description:
Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. When don't throw an exception when you try in use a ton of resources in a thousand other ways.

The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.

I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

  was:
Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens it because a user built the boolean themselves. And no duh thousands more boolean queries means slower perf and more resources needed. When don't throw an exception when you try in use a ton of resources in a thousand other ways.

The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.

I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.


> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. When don't throw an exception when you try in use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated LUCENE-2018:
--------------------------------

    Description:
Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.

The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.

I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

  was:
Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. When don't throw an exception when you try in use a ton of resources in a thousand other ways.

The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.

I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.


> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771547#action_12771547 ]

Michael McCandless commented on LUCENE-2018:
--------------------------------------------

I think removing it makes sense?

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771554#action_12771554 ]

Yonik Seeley commented on LUCENE-2018:
--------------------------------------

Fuzzy query uses it to limit terms.  Any others?

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771558#action_12771558 ]

Mark Miller commented on LUCENE-2018:
-------------------------------------

Ah, right - not the first time I've forgotten Fuzzy didnt get the new rewrite treatment.

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated LUCENE-2018:
--------------------------------

    Fix Version/s: 3.1

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>             Fix For: 3.1
>
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787658#action_12787658 ]

Mark Miller commented on LUCENE-2018:
-------------------------------------

I still think this should be removed - or moved to the MTQ query itself - then a setting on the queryparser could set it, or a user could set it. It shouldn't be a sys property, and I don't necessarily think it should be on by default either.

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>             Fix For: 3.1
>
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787670#action_12787670 ]

Michael McCandless commented on LUCENE-2018:
--------------------------------------------

bq. I still think this should be removed -

+1

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>             Fix For: 3.1
>
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2018) Reconsider boolean max clause exception

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787674#action_12787674 ]

Uwe Schindler commented on LUCENE-2018:
---------------------------------------

+1.

And Fuzzy Query's PQ then would use the MTQ value as max size.

> Reconsider boolean max clause exception
> ---------------------------------------
>
>                 Key: LUCENE-2018
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2018
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>             Fix For: 3.1
>
>
> Now that we have smarter multi-term queries, I think its time to reconsider the boolean max clause setting. It made more sense before, because you could hit it more unaware when the multi-term queries got huge - now its more likely that if it happens its because a user built the boolean themselves. And no duh thousands more boolean clauses means slower perf and more resources needed. We don't throw an exception when you try to use a ton of resources in a thousand other ways.
> The current setting also suffers from the static hell argument - especially when you consider something like Solr's multicore feature - you can have different settings for this in different cores, and the last one is going to win. Its ugly. Yes, that could be addressed better in Solr as well - but I still think it should be less ugly in Lucene as well.
> I'd like to consider either doing away with it, or raising it by quite a bit at the least. Or an alternative better solution. Right now, it aint so great.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]