14 March 2019, Apache Solr™ 8.0.0 available
The Lucene PMC is pleased to announce the release of Apache Solr 8.0.0
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted s
11 February 2019, Apache Solr™ 7.7.0 available
The Lucene PMC is pleased to announce the release of Apache Solr 7.7.0
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, facete
24 September 2018, Apache Solr™ 7.5.0 available
The Lucene PMC is pleased to announce the release of Apache Solr 7.5.0
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, facet
15 January 2018, Apache Solr™ 7.2.1 available
The Lucene PMC is pleased to announce the release of Apache Solr 7.2.1
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted
27 April 2017, Apache Solr™ 6.5.1 available
The Lucene PMC is pleased to announce the release of Apache Solr 6.5.1
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted
27 April 2017, Apache Solr™ 6.5.1 available
The Lucene PMC is pleased to announce the release of Apache Solr 6.5.1
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted s
27 April 2017, Apache Solr™ 6.5.1 available
The Lucene PMC is pleased to announce the release of Apache Solr 6.5.1
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted s
27 March 2017, Apache Solr 6.5.0 available
The Lucene PMC is pleased to announce the release of Apache Solr 6.5.0.
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted s
Java 8 update
121, use an earlier version instead! This is caused by a bug introduced
into the Javadocs tool shipped with that update. The workaround was too
late for this Lucene release. Of course, you can use the binary artifacts.
See the Solr CHANGES.txt files included with the release for a full list of
details.
Thanks,
Jim Ferenczi
r up to 4.3).
2015-11-02 13:47 GMT+01:00 Modassar Ather :
> The problem is with the same query as phrase. q="network se*".
>
> The last . is fullstops for the sentence and the query is q=field:"network
> se*"
>
> Best,
> Modassar
>
> On Mon, Nov 2, 2015
based on the frequency of the words for instance).
2015-11-02 13:36 GMT+01:00 jim ferenczi :
>
>
>
> *I am not able to get the above point. So when I start Solr with 28g RAM,
> for all the activities related to Solr it should not go beyond 28g. And the
> remaining heap will be
that only machine is used so I assumed that 400% cpu is for a
> single process (one solr node), right ?
> Yes you are right that 400% is for single process.
> The disks are SSDs.
>
> Regards,
> Modassar
>
> On Mon, Nov 2, 2015 at 4:09 PM, jim ferenczi
> wrote:
>
> &g
11:38 GMT+01:00 jim ferenczi :
> 12 shards with 28GB for the heap and 90GB for each index means that you
> need at least 336GB for the heap (assuming you're using all of it which may
> be easily the case considering the way the GC is handling memory) and ~=
> 1TO for the index. Le
12 shards with 28GB for the heap and 90GB for each index means that you
need at least 336GB for the heap (assuming you're using all of it which may
be easily the case considering the way the GC is handling memory) and ~=
1TO for the index. Let's say that you don't need your entire index in RAM,
the
> In part of queries we see strange behavior where q performs 5-10x better
> than fq. The question is why?
Are you sure that the query result cache is disabled ?
2015-06-24 13:28 GMT+02:00 Esther Goldbraich :
> Hi,
>
> We are comparing the performance of fq versus q for queries that are
> actuall
Then you just have to remove the group.sort especially if your group limit
is set to 1.
Le 19 mars 2015 16:57, "kumarraj" a écrit :
> *if the number of documents in one group is more than one then you cannot
> ensure that this document reflects the main sort
>
> Is there a way the top record whic
Hi Raj,
The group.sort you are using defines multiple criterias. The first criteria
is the big solr function starting with the "max". This means that inside
each group the documents will be sorted by this criteria and if the values
are equals between two documents then the comparison fallbacks to t
Hi,
Please note that you have two sort criteria, one to sort the documents
inside each group and one to sort the groups. In the example you sent, the
group 10002 has two documents and your group.limit is set to 1. If you redo
the query with group.limit=2 I suspect that you'll see the second documen
I think you should test with facet.shard.limit=-1 this will disallow the
limit for the facet on the shards and remove the needs for facet
refinements. I bet that returning every facet with a count greater than 0
on internal queries is cheaper than using the filter cache to handle a lot
of refinemen
Hi,
Something like ?:
https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component
And just to show some impressive search functionality of the wiki: ;)
https://cwiki.apache.org/confluence/dosearchsite.action?where=solr&spaceSearch=true&queryString=document+vectors
Cheers,
Jim
2014
Hi Bryan,
This is a known limitations of the grouping.
https://wiki.apache.org/solr/FieldCollapsing#RequestParameters
group.ngroups:
*WARNING: If this parameter is set to true on a sharded environment, all
the documents that belong to the same group have to be located in the same
shard, otherwis
Hi Per,
First of all the BloomFilter implementation in Lucene is not exactly a
bloom filter. It uses only one hash function and you cannot set the false
positive ratio beforehand. ElasticSearch has its own bloom filter
implementation (using "guava like" BloomFilter), you should take a look at
their
@William Firstly because I was sure that the ticket (or an equivalent) was
already opened but I just could not find it. Thanks @Manuel. Secondly
because I wanted to start the discussion, I have the feeling that the
compression of the documents, activated by default, can be a killer for
some applica
Dear Solr users,
we migrated our solution from Solr 4.0 to Solr 4.3 and we noticed a
degradation of the search performance. We compared the two versions and
found out that most of the time is spent in the decompression of the
retrievable fields in Solr 4.3. The block compression of the documents i
Hi,
If you are not on windows, you can try to disable the tracking of clones in
the MMapDirectory by setting unmap to false in your solrconfig.xml:
* *
* false*
**
The MMapDirectory keeps track of all clones in a weak map and forces the
unmapping of the buffers on close. This was added because
Hi Rohit,
The main problem is that if the query inside the filter does not have a
PostFilter implementation then your post filter is silently transformed
into a simple filter. The query "field:value" is based on the inverted
lists and does not have a postfilter support.
If your field is a numeric f
26 matches
Mail list logo
