lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Atri Sharma (JIRA)" <>
Subject [jira] [Commented] (LUCENE-8708) Can we simplify conjunctions of range queries automatically?
Date Wed, 01 May 2019 11:52:00 GMT


Atri Sharma commented on LUCENE-8708:

ToStringInteface is a necessary evil required to create new PointRangeQuery instances post
the merging of the interval. In the current state of affairs, BooleanQuery has no visibility
into the type of the range query that it is dealing with (which is a great thing). However,
that limits the ability to create new range queries of the parent type directly. ToStringInterface
allows a polymorphic way to allow new range queries to be created in BooleanQuery.rewrite.


Regarding testInvalidPointLength, that test needs to be refactored to work with ToStringInterface.
However, since that is not a blocker to the actual functionality, I chose not to spend time
on it until we have more clarity on the direction in which we wish to head.

> Can we simplify conjunctions of range queries automatically?
> ------------------------------------------------------------
>                 Key: LUCENE-8708
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Priority: Minor
>         Attachments: interval_range_clauses_merging0704.patch
> BooleanQuery#rewrite already has some logic to make queries more efficient, such as deduplicating
filters or rewriting boolean queries that wrap a single positive clause to that clause.
> It would be nice to also simplify conjunctions of range queries, so that eg. {{foo: [5
TO *] AND foo:[* TO 20]}} would be rewritten to {{foo:[5 TO 20]}}. When constructing queries
manually or via the classic query parser, it feels unnecessary as this is something that the
user can fix easily. However if you want to implement a query parser that only allows specifying
one bound at once, such as Gmail ({{after:2018-12-31}}
or GitHub ({{updated:>=2018-12-31}}
then you might end up with inefficient queries if the end user specifies both an upper and
a lower bound. It would be nice if we optimized those automatically.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message