older ones, see:
http://wiki.apache.org/solr/LotsOfCores
Best,
Erick
On Mon, Aug 3, 2015 at 4:57 PM, Brian Hurt bhur...@gmail.com wrote:
Is there are an easy way for a client to tell Solr to close or release
the
IndexSearcher and/or IndexWriter for a core?
I have a use case where we're
:57 PM, Brian Hurt bhur...@gmail.com wrote:
Is there are an easy way for a client to tell Solr to close or release the
IndexSearcher and/or IndexWriter for a core?
I have a use case where we're creating a lot of cores with not that many
documents per zone (a few hundred to maybe 10's
Is there are an easy way for a client to tell Solr to close or release the
IndexSearcher and/or IndexWriter for a core?
I have a use case where we're creating a lot of cores with not that many
documents per zone (a few hundred to maybe 10's of thousands). Writes come
in batches, and reads also
I seem to recall somewhere in the documention that the create function on
non-cloud solr doesn't copy the config files in, you have to copy them in
by hand. Is this correct? If so, can anyone point me to where in the docs
it says this, and if there are any plans to change this? Thanks.
Brian
I have a situation which is common in our current use case, where I need to
get a large number (many hundreds) of documents by id. What I'm doing
currently is creating a large query of the form id:12345 OR id:23456 OR
... and sending it off. Unfortunately, this query is taking a long time,
, it doesn't seem to be working. (Anonymous - via GTD book)
On Thu, Jul 18, 2013 at 10:46 AM, Brian Hurt bhur...@gmail.com wrote:
I have a situation which is common in our current use case, where I need
to
get a large number (many hundreds) of documents by id. What I'm doing
currently is creating
So, I'm executing the following query:
id:6178dB=@Fm AND i_0:613OFS AND (i_3:6111 OR i_3:1yyy\~) AND (NOT
id:6178ZwWj5m OR numfields:[* TO 6114] OR d_4:false OR NOT
i_4:6142E=m)
It's machine generated, which explains the redundancies. The problem is
that the query returns no results- but there
Thanks for your reponse. You've given me some solid leads.
On Wed, Apr 24, 2013 at 11:25 AM, Shawn Heisey s...@elyograg.org wrote:
On 4/24/2013 8:59 AM, Brian Hurt wrote:
So, I'm executing the following query:
id:6178dB=@Fm AND i_0:613OFS AND (i_3:6111 OR i_3:1yyy\~) AND
(NOT
id
On Mon, Mar 18, 2013 at 7:08 PM, Jack Krupansky j...@basetechnology.com wrote:
Hmmm... if query by your unique key field is killing your performance, maybe
you have some larger problem to address.
This is almost certainly true. I'm well outside the use cases
targeted by Solr/Lucene, and it's a
So here's the problem I'm trying to solve: in my use case, all my
documents have a unique id associated with them (a string), and I very
often need to get them by id. Currently I'm doing a search on id, and
this takes long enough it's killing my performance. Now, it looks
like there is a GET
10 matches
Mail list logo
