I think my original post didn't go through because I wasn't subscribed so
apologizes if this is a duplicate.
For both Solr 7 and Solr 8, we have found that attempts to do range queries on
DatePointField when there are a large number of points performs poorly (queries
were taki
For both Solr 7 and Solr 8, we have found that attempts to do range queries on
DatePointField when there are a large number of points performs poorly (queries
were taking over 30 seconds on a 50G core). We also tried switching to
IntPointField to see if it made a difference and it didn't.
Thanks!
-Original message-
> From:Shawn Heisey
> Sent: Tuesday 24th October 2017 19:04
> To: solr-user@lucene.apache.org
> Subject: Re: Date range queries no longer work 6.6 to 7.1
>
> On 10/24/2017 9:38 AM, Markus Jelsma wrote:
> > We have switched back to 6.
On 10/24/2017 9:38 AM, Markus Jelsma wrote:
> We have switched back to 6.6 for now so we are fine for now. Although i
> didn't try range queries other than date, i assume other Point fields can
> also have this problem?
>
> That would mean completely switch back to Trie if y
On 10/24/2017 9:25 AM, Markus Jelsma wrote:
> No, we have not reindexed, we don't like to reindex one of our collections,
> it is huge!
>
> Didn't know about a index migration tool, i have not seen it in the changelog.
If you change the class on a field (in this case, probably Trie to
Point), th
We have switched back to 6.6 for now so we are fine for now. Although i didn't
try range queries other than date, i assume other Point fields can also have
this problem?
That would mean completely switch back to Trie if you don't can/want to fully
reindex all data.
Suggestions? A
; From:alessandro.benedetti
>> Sent: Tuesday 24th October 2017 17:03
>> To: solr-user@lucene.apache.org
>> Subject: Re: Date range queries no longer work 6.6 to 7.1
>>
>> I know it is obvious, but ...
>> have you done a full re-indexing
17:03
> To: solr-user@lucene.apache.org
> Subject: Re: Date range queries no longer work 6.6 to 7.1
>
> I know it is obvious, but ...
> have you done a full re-indexing or you used the Index migration tool ?
> In the latter case, it could be a bug of the tool itself.
>
>
&
I know it is obvious, but ...
have you done a full re-indexing or you used the Index migration tool ?
In the latter case, it could be a bug of the tool itself.
-
---
Alessandro Benedetti
Search Consultant, R&D Software Engineer, Director
Sease Ltd. - www.sease.io
--
Sent from: h
Hello,
We just attempted an upgrade which went fine so far. But now we have a problem,
date range queries can no longer find records from before the upgrade, only
records after the upgrade, it probably has something to do with DatePointField.
To be clear, we upgraded our old date fields to the
Hi Mikhail,
Range queries allowed inside phrases with ComplexPhraseQParser, but I think
string order is used.
Also LUCENE-5205 / SOLR-5410 is meant to supersede complex phrase. It might
have that functionality too.
Ahmet
On Tuesday, December 2, 2014 10:43 PM, Mikhail Khludnev
wrote
On 12/02/2014 03:41 PM, Mikhail Khludnev wrote:
Thanks for suggestions. Do I remember correctly that you ignored last
Lucene Revolution?
I wouldn't say I ignored it, but it's true I wasn't there in DC: I'm
excited to catch up on the presentations as the videos become available,
though.
-Mike
Hello Michael,
On Tue, Dec 2, 2014 at 11:15 PM, Michael Sokolov <
msoko...@safaribooksonline.com> wrote:
> Mikhail - I can imagine a filter that strips out everything but numbers
> and then indexes those with a (separate) numeric (trie) field. But I don't
> believe you can do phrase or other pro
Mikhail - I can imagine a filter that strips out everything but numbers
and then indexes those with a (separate) numeric (trie) field. But I
don't believe you can do phrase or other proximity queries across
multiple fields. As long as an or-query is good enough, I think this
problem is not to
Hello Searchers,
Don't you remember any examples of indexing numbers inside of plain text.
eg. if I have a text: "foo and 10 bars" I want to find it with a query like
foo [8 TO 20] bars.
The question no.1 whether to put trie terms into the separate field or they
can reside at the same text one? No
> will be different after they are parsed and NOW is converted to an
> >> actual timestamp.
> >>
> >> > Also, if you are using TrieDateField, precisionStep value is how
> >> > optimization is done. There is bucketing at different level of
> >> &g
imes several seconds apart, every one of those queries
>> will be different after they are parsed and NOW is converted to an
>> actual timestamp.
>>
>> > Also, if you are using TrieDateField, precisionStep value is how
>> > optimization is done. There is bucketing a
ere is bucketing at different level of
> > precision, so the range search works at the least granular level
> > first, etc.
>
> Some nitty-gritty details of how range queries are accelerated with the
> Trie data types and precisionStep are described in the Javadoc fo
ent level of
> precision, so the range search works at the least granular level
> first, etc.
Some nitty-gritty details of how range queries are accelerated with the
Trie data types and precisionStep are described in the Javadoc for
NumericRangeQuery:
http://lucene.apache.org/core/4_8_0/core
, that in order to
> optimize the date range queries, it is beneficial to round down the range
> values.
>
> For example, if a range query is:
>
> DateTime:[NOW-3DAYS TO NOW]
>
> then if the precision up to msec is not required, we can safely round that
> down to a day or
exact query matches such as year without expanding
the date to a range for the full interval.
-- Jack Krupansky
-Original Message-
From: Dmitry Kan
Sent: Friday, May 9, 2014 6:41 AM
To: solr-user@lucene.apache.org
Subject: date range queries efficiency
Hi,
There was a mention eith
Hi,
There was a mention either on solr wiki or on this list, that in order to
optimize the date range queries, it is beneficial to round down the range
values.
For example, if a range query is:
DateTime:[NOW-3DAYS TO NOW]
then if the precision up to msec is not required, we can safely round
gt; > Erick
> >
> >
> > On Wed, Jan 8, 2014 at 11:56 AM, Kranti Parisa > >wrote:
> >
> > > I was trying with the [* TO *] as an example, the real use case is OR
> > > query between 2/more range queries of timestamp fields (saved in
> > >
On Wed, Jan 8, 2014 at 11:56 AM, Kranti Parisa >wrote:
>
> > I was trying with the [* TO *] as an example, the real use case is OR
> > query between 2/more range queries of timestamp fields (saved in
> > milliseconds). So I can't use FQs as they are ANDed by definition
the first one.
>>
>> It kind of depends on the query pattern whether the filtercache will be
>> re-used, you have to take care to construct the fq clauses with re-use
>>in
>> mind if you want ORs.
>>
>> Best,
>> Erick
>>
>>
>> On Wed,
; mind if you want ORs.
> >
> > Best,
> > Erick
> >
> >
> > On Wed, Jan 8, 2014 at 11:56 AM, Kranti Parisa > >wrote:
> >
> > > I was trying with the [* TO *] as an example, the real use case is OR
> > > query between 2/more range que
Erick
>
>
> On Wed, Jan 8, 2014 at 11:56 AM, Kranti Parisa >wrote:
>
> > I was trying with the [* TO *] as an example, the real use case is OR
> > query between 2/more range queries of timestamp fields (saved in
> > milliseconds). So I can't use FQs as they are AN
I was trying with the [* TO *] as an example, the real use case is OR
> query between 2/more range queries of timestamp fields (saved in
> milliseconds). So I can't use FQs as they are ANDed by definition.
>
> Am I missing something here?
>
>
>
>
> Thanks,
&g
I was trying with the [* TO *] as an example, the real use case is OR
query between 2/more range queries of timestamp fields (saved in
milliseconds). So I can't use FQs as they are ANDed by definition.
Am I missing something here?
Thanks,
Kranti K. Parisa
http://www.linkedin.c
:26 PM
> To: solr-user@lucene.apache.org
> Subject: Range queries with Grouping is slow?
>
> Is there any known issue with Range queries + grouping?
>
> Case1:
> q=id:123&group=true&sort=price
> asc&group.field=entityId&group.limit=2&group.ngroups=true
&g
anuary 07, 2014 10:26 PM
To: solr-user@lucene.apache.org
Subject: Range queries with Grouping is slow?
Is there any known issue with Range queries + grouping?
Case1:
q=id:123&group=true&sort=price
asc&group.field=entityId&group.limit=2&group.ngroups=true
Case2:
q=id:123 AND p
Is there any known issue with Range queries + grouping?
Case1:
q=id:123&group=true&sort=price
asc&group.field=entityId&group.limit=2&group.ngroups=true
Case2:
q=id:123 AND price:[* TO *]&group=true&sort=price
asc&group.field=entityId&group.limit=2&group
>
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Use-function-return-value-for-range-queries-tp4093499.html
> Sent from the Solr - User mailing list archive at Nabble.com.
Thank you very much Jack.
I will take a look at this.
Bests Sandro
--
View this message in context:
http://lucene.472066.n3.nabble.com/Use-function-return-value-for-range-queries-tp4093499p4093579.html
Sent from the Solr - User mailing list archive at Nabble.com.
October 04, 2013 10:53 AM
To: solr-user@lucene.apache.org
Subject: AW: Use function return value for range queries
Thanks for the quick answer. I thought that :-)
Is there any plan add such a functionality in the future. Or is it
completely against the concept.
Bests Sandro
-Ursprüngliche
: solr-user@lucene.apache.org
Betreff: Re: Use function return value for range queries
I think the best you can do is compute sum(pricea,priceb) at index time as a
third field, say priceSum, and then you can do a range query on that priceSum
field.
It would be nice to be able to have a query that
ssage-
From: SandroZbinden
Sent: Friday, October 04, 2013 10:21 AM
To: solr-user@lucene.apache.org
Subject: Use function return value for range queries
Is there a way to use the function return value for a range query
For example: I have two price fields pricea and priceb and now i want to get
the v
ulate this at index time.
Bests Sandro
--
View this message in context:
http://lucene.472066.n3.nabble.com/Use-function-return-value-for-range-queries-tp4093499.html
Sent from the Solr - User mailing list archive at Nabble.com.
Krupansky
-Original Message-
From: SolrLover
Sent: Wednesday, August 07, 2013 5:53 PM
To: solr-user@lucene.apache.org
Subject: Is it possible to use phrase query in range queries?
I am trying to use range queries to take advantage of having constant scores
in multivalued field but I am not sur
I am trying to use range queries to take advantage of having constant scores
in multivalued field but I am not sure if range queries support phrase
query..
Ex:
The below range query works fine.
_query_:"address:([Charlotte TO Charlotte])"^5.5
The below query doesn't work,
_
--Original Message-
From: Paul Wellner Bou
Sent: Wednesday, July 24, 2013 11:29 AM
To: solr-user@lucene.apache.org
Subject: Unexpected search results with date range queries and OR
Dear Solr-list,
We are experimenting an unexpected behaviour of solr using date range
queries combined with OR. The u
Dear Solr-list,
We are experimenting an unexpected behaviour of solr using date range
queries combined with OR. The use case is (reduced to this simple
example): We want to get all content which does not have the offTime
field defined or, if the offTime field is defined, it should be in the
: After some research the following syntax worked
: start_time_utc_epoch:[1970-01-01T00:00:00Z TO
: _val_:"merchant_end_of_day_in_utc_epoch"])
that syntax definitely does not work ... i don't know if there is a typo
in your mail, or if you are just getting strange results that happen to
look li
Yes, the SQL statement is what I am trying to achieve. As for the
merchant_end_of_day_in_utc_epoch, we map the time to start of epoch and
convert that to UTC, so that all the merchants are in the same timezone
which would make it easier to query for open ones.
For the use case when we need to dete
Erick,
I believe Indika wants to do this SQL WHERE clause in Solr:
WHERE start_time_utc_epoch >= '1970-01-01T00:00:00Z' AND start_time_utc_epoch
<= merchant_end_of_day_in_utc_epoch
On Tue, Apr 30, 2013 at 11:49 AM, Erick Erickson wrote:
> Could you define your use-case in some more detail? On t
Could you define your use-case in some more detail? On the
surface, this query doesn't really make a lot of sense. How
would merchant_end_of_day_in_utc_epoch be determined?
Presumably there are zillions of values across your index for
this value, depending on the document. Which one should be
used?
al Message-
From: Shawn Heisey [mailto:s...@elyograg.org]
Sent: Tuesday, February 05, 2013 2:53 PM
To: solr-user@lucene.apache.org
Subject: Re: Really bad query performance for date range queries
On 2/5/2013 3:19 PM, Petersen, Robert wrote:
> Hi Shawn,
>
> I've looked at th
On 2/5/2013 3:19 PM, Petersen, Robert wrote:
Hi Shawn,
I've looked at the xing JVM before but don't use it. jHiccup looks like a
really useful tool. Can you tell us how you are starting it up? Do you start
it wrapping the app container (ie tomcat / jetty)?
Instead of just calling /usr/bin
[mailto:s...@elyograg.org]
Sent: Tuesday, February 05, 2013 1:27 PM
To: solr-user@lucene.apache.org
Subject: Re: Really bad query performance for date range queries
On 2/5/2013 12:51 PM, sausarkar wrote:
> We have a 96GB ram machine with 16 processors. the JVM is set to use 60 GB.
> The test that we
On 2/5/2013 12:51 PM, sausarkar wrote:
We have a 96GB ram machine with 16 processors. the JVM is set to use 60 GB.
The test that we are running are purely query there is no indexing going on.
I dont see garbage collection when I attach visualVM but see frequent CPU
spikes ~once every minute.
A
://lucene.472066.n3.nabble.com/Really-bad-query-performance-for-date-range-queries-tp4038435p4038633.html
Sent from the Solr - User mailing list archive at Nabble.com.
t freezes. Is there
> a way to cure this?
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Really-bad-query-performance-for-date-range-queries-tp4038435p4038455.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
this?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Really-bad-query-performance-for-date-range-queries-tp4038435p4038455.html
Sent from the Solr - User mailing list archive at Nabble.com.
: Monday, February 04, 2013 4:48 PM
To: solr-user@lucene.apache.org
Subject: Really bad query performance for date range queries
we are experiencing very bad performance issues with date range queries. We
have configured the date fields as following: Our queries are rounded every
minute:
qt=ads&debu
9:30 AM
To: solr-user@lucene.apache.org
Subject: Range Queries performing differently on SortableIntField vs
TrieField of type integer
Greetings,
I'm finally updating an old instance and in testing, discovered that using
the recommended TrieField instead of SortableIntField for range querie
can't seem to reproduce this.
Here's what i tried...
1) start up the Solr 3.6.1 example
2) index the 3.6.1 example docs...
java -jar post.jar *.xml
3) index a single doc using some "*_ti" dynamic fields (which us
"tint")...
java -Ddata=args -jar post.jar 'HOSS4510
I forgot a possibly important piece... Given the different Solr versions,
the schema version (and it's related different defaults) is also a change:
Solr 1.4.1 Has:
Solr 3.6.1 Has:
> Solr 1.4.1 Relevant Schema Parts - Working as desired:
> >
>
Hi Upayavira,
One small question - did you re-index in-between? The index structure
> will be different for each.
>
Yes, the Solr 1.4.1 (working) instance was built using the original schema
and that solr version.
The Solr 3.6.1 (not working) instance was re-built using the new schema and
Solr 3.
TrieField instead of SortableIntField for range queries
> returns unexpected and seemingly incorrect results.
>
> A query with:
>
> q=*:*&fq=+i_yearStartSort:{* TO 1995}&fq=+i_yearStopSort:{* TO *}
>
> Should, and does under 1.4.1 with SortableIntField, only return do
: query is price: [ 1 TO 20 ] is returning values out of this range ,like
: 23.00 AND 55.00 .The field type of the price field is sfloat .
can you provide more details about the documents matching out of the
range? are you sure this isn't a multivalued field?
: When I check this form admin Deb
On Thu, Mar 29, 2012 at 6:44 PM, Alexandre Rocco wrote:
> Yonik,
>
> Thanks for the heads-up. That one worked.
>
> Just trying to wrap around how it would work on a real case. To test this
> one I just got the coordinates from Google Maps and searched within the pair
> of coordinates as I got them
query?
I know that this one is off-topic, just curious.
Thanks
Alexandre
On Thu, Mar 29, 2012 at 7:26 PM, Yonik Seeley wrote:
> On Thu, Mar 29, 2012 at 6:20 PM, Alexandre Rocco
> wrote:
> > http://localhost:8984/solr/select?q=*:*&fq=local:[-23.6677,-46.7315 TO
> > -23.67
On Thu, Mar 29, 2012 at 6:20 PM, Alexandre Rocco wrote:
> http://localhost:8984/solr/select?q=*:*&fq=local:[-23.6677,-46.7315 TO
> -23.6709,-46.7261]
Range queries always need to be [lower_bound TO upper_bound]
Try
http://localhost:8984/solr/select?q=*:*&fq=local:[-23.6709,-46.73
Erick,
Just checked on the separate fields and everything looks fine.
One thing that I'm not completely sure is if this query I tried to perform
is correct.
One sample document looks like this:
200
-23.6696784,-46.7290193
-23.6696784
-46.7290193
So, to find for this document I tried to create
This all looks fine, so the next question is whether or not your
documents have the value you think.
+local_0_coordinate:[-23.6674 TO -23.6705] +local_1_coordinate:[-46.7314 TO
-46.7274]
is the actual translated filter.
So I'd check the actual documents in the index to see if you have a single
do
Erick,
My location field is defined like in the example project:
Also, there is the dynamic that stores the splitted coordinates:
The response XML with debugQuery=on is looking like this:
0
1
*:*
*:*
MatchAllDocsQuery(*:*)
*:*
LuceneQParser
local:[-23.6674,-46.7314 TO -23.6705,-46.7274]
What are your results? Can you show us the field definition for "local"
and the results of adding &debugQuery=on?
Because this should work as far as I can tell.
Best
Erick
On Thu, Mar 29, 2012 at 11:04 AM, Alexandre Rocco wrote:
> Hello,
>
> I'm trying to perform some queries on a location fiel
Hello,
I'm trying to perform some queries on a location field on the index.
The requirement is to search listings inside a pair of coordinates, like a
bounding box.
Taking a look on the wiki, I noticed that there is the option to use the
bbox query but in does not create a retangular shaped box t
Hello,
I am having an issue with range query in solr 1.3 .
query is price: [ 1 TO 20 ] is returning values out of this range ,like
23.00 AND 55.00 .The field type of the price field is sfloat .
When I check this form admin Debug query ,I am seeing junk instead of price.
example:
price:[ 1 TO 2
On Tue, Jan 3, 2012 at 12:36 AM, Michael Ryan wrote:
> I was wondering... how does the TrieField precisionStep value affect the
> speed of non-range queries and sorting?
>
> I'm assuming that int (precisionStep=0) is no slower than tint
> (precisionStep=8) for these - is th
I was wondering... how does the TrieField precisionStep value affect the speed
of non-range queries and sorting?
I'm assuming that int (precisionStep=0) is no slower than tint
(precisionStep=8) for these - is that correct? tint is just faster for range
queries?
Is int any faster than
On Sat, Jul 9, 2011 at 8:04 PM, Lance Norskog wrote:
> Does the Join feature work with Range queries?
Not in any generic manner - joins are based on exact matches of
indexed tokens only.
But if you wanted something specific enough like same year, then you
could index that year for each docum
Does the Join feature work with Range queries?
Given a time series of events stored as documents with time ranges, is
it possible to do a search that finds certain events, and then add
other documents whose time ranges overlap?
--
Lance Norskog
goks...@gmail.com
-item-multiple-fields-and-range-queries-tp475030p2796613.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi,
I am sorry to ask this silly question but I could not find the
documentation about this and I am very new to lucene solr. I want to run a
range query on one of the multivalued field e.g. I have a point say [10,20],
which is the point of intersection of the diagonals of a rectangle. Now I
w
e field
> (float)
> definition to achieve optimal performance?
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Randomly-slow-response-times-for-range-queries-tp1441724p1443096.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
Also, does anyone know the best precisionStep to use on a trie field (float)
definition to achieve optimal performance?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Randomly-slow-response-times-for-range-queries-tp1441724p1443096.html
Sent from the Solr - User mailing
ge in context:
http://lucene.472066.n3.nabble.com/Randomly-slow-response-times-for-range-queries-tp1441724p1443086.html
Sent from the Solr - User mailing list archive at Nabble.com.
eg.gnatovskiy wrote:
>
> Hello all,
>
> I am running two range queries on a double value as filter queries using
> Solr 1.4, and for the most part am getting great performance (qTime <
> 100ms). However, at certain QPS, I start getting very slow queries
> (2000+ms). I'v
Hello all,
I am running two range queries on a double value as filter queries using
Solr 1.4, and for the most part am getting great performance (qTime <
100ms). However, at certain QPS, I start getting very slow queries
(2000+ms). I've tried this using the new trie fields, and using
: lastModified:[ms(NOW/DAY-1DAY) TO ms()] AND ... regular query ...
:
: This however doesn't work. If I use the following:
...
: lastModified:[128081160 TO ms()] AND ... regular query ...
:
: I do get results.
Are you sure that last example works? it shouldn't.
If lastModif
e' is...
: perform numeric range queries and return the result in logical ordering. I
: was thinking about using either TrieField classes for int, double etc..
: and/or SortableIntField, SortableLongField classes defined in solr to
: perform range query search in dspace.
if you can customize t
Hi,
I use Nutch and Solr to crawl a few thousand sites. I would like to
limit my queries to recently changed documents. I use Nutch' index-more
plugin which stores the Last-Modified HTTP response header in the index
as a Long value.
I would like to use a query like this to limit the results
,SortableIntField, etc.. can be use to
perform numeric range queries and return the result in logical ordering. I
was thinking about using either TrieField classes for int, double etc..
and/or SortableIntField, SortableLongField classes defined in solr to
perform range query search in dspace.
-Mckeane
wser/trunk/dspace/src/org/dspace/search/DSIndexer.java?rev=970
...i'm going to assume that's what you are talking about.
: numerical range queries using either TrieIntField,
: TrieDoubleField,TrieLongField, etc.. classes defined in Solr's api or
: SortableIntFiel
I'm trying to use dspace to search across a range of index created and stored
using Dsindexer.java class. I have seen where Solr can be use to perform
numerical range queries using either TrieIntField,
TrieDoubleField,TrieLongField, etc.. classes defined in Solr's api or
SortableInt
> Hi all,
>
> I have a problem with range queries on an integer field.
> (Solr 1.4)
>
> In my index, myField contains values between 0 and 3000.
>
> stored="true" required="false"/>
>
> Here are a few samples to give you an idea of t
Hi all,
I have a problem with range queries on an integer field. (Solr 1.4)
In my index, myField contains values between 0 and 3000.
Here are a few samples to give you an idea of the problem:
fq=myField:[1 TO 1000] ... 0 results
fq=myField:[1 TO 999] ... 1288930 results
fq=myField:[1 TO
For now I need them, I will however most likely (as suggested by Ahmet Arslan),
create another boolean field to get rid of them, just simply due to the fact
that I am switching to Solr 1.4 frange queries.
On the topic of frange queries, is there a way to simulate the date range
wildcards here?
Do you really need the *:* stuff in the date range subqueries? That
may add to the execution time.
On Thu, Apr 29, 2010 at 9:52 AM, Erick Erickson wrote:
> Hmmm, what does the rest of your query look like? And does adding
> &debugQuery=on show anything interesting?
>
> Best
> Erick
>
> On Thu, Ap
Hmmm, what does the rest of your query look like? And does adding
&debugQuery=on show anything interesting?
Best
Erick
On Thu, Apr 29, 2010 at 6:54 AM, Jan Simon Winkelmann <
winkelm...@newsfactory.de> wrote:
> > > ((valid_from:[* TO 2010-04-29T10:34:12Z]) AND
> > > (valid_till:[2010-04-29T10:34
-Original Message-
From: Jan Simon Winkelmann [mailto:winkelm...@newsfactory.de]
Sent: Thursday, April 29, 2010 4:36 AM
To: solr-user@lucene.apache.org
Subject: Slow Date-Range Queries
Hi,
I am currently having serious performance problems with date range queries.
What I am doing, is validating
> > ((valid_from:[* TO 2010-04-29T10:34:12Z]) AND
> > (valid_till:[2010-04-29T10:34:12Z TO *])) OR ((*:*
> > -valid_from:[* TO *]) AND (*:* -valid_till:[* TO *])))
> >
> > I use the empty checks for datasets which do not have a
> > valid from/till range.
> >
> >
> > Is there any way to get this any
> I am currently having serious performance problems with
> date range queries. What I am doing, is validating a
> datasets published status by a valid_from and a valid_till
> date field.
>
> I did get a performance boost of ~ 100% by switching from a
> norma
Hi,
I am currently having serious performance problems with date range queries.
What I am doing, is validating a datasets published status by a valid_from and
a valid_till date field.
I did get a performance boost of ~ 100% by switching from a normal
solr.DateField to a solr.TrieDateField
Sure. Will take a look. Thanks, Ankit.
-Original Message-
From: Ankit Bhatnagar [mailto:abhatna...@vantage.com]
Sent: Wednesday, April 14, 2010 6:52 PM
To: 'solr-user@lucene.apache.org'
Subject: RE: solr numeric range queries
Hi Sandhya,
On a different note - if you are usi
...@opentext.com]
Sent: Wednesday, April 14, 2010 7:56 AM
To: solr-user@lucene.apache.org
Subject: RE: solr numeric range queries
Thanks Erik. I did read through the document mentioned, but was a little
surprised that there is no direct syntax for "<=", "<" etc;. Hence, was
con
ay, April 14, 2010 5:09 PM
To: solr-user@lucene.apache.org
Subject: Re: solr numeric range queries
On Apr 14, 2010, at 6:09 AM, Sandhya Agarwal wrote:
> Hello,
>
> As I understand, we have to use the syntax { * TO } or [ *
> TO ], for queries less than or less than or equal
>
On Apr 14, 2010, at 6:09 AM, Sandhya Agarwal wrote:
Hello,
As I understand, we have to use the syntax { * TO } or [ *
TO ], for queries less than or less than or equal
to , etc;
Where is a numeric field.
There is no direct < or <= syntax supported. Is that
correct ?
That's c
Hello,
As I understand, we have to use the syntax { * TO } or [ * TO
], for queries less than or less than or equal to , etc;
Where is a numeric field.
There is no direct < or <= syntax supported. Is that correct ?
Thanks,
Sandhya
1 - 100 of 148 matches
Mail list logo
