(with +) to the from side
query.
On Tue, Jun 24, 2014 at 8:09 PM, Kevin Stone wrote:
> Is there any way to limit the results of a query on the "from" index
> before it gets joined?
>
> The SQL analogy might be...
> SELECT *
> from toIndex join
> (select * from fr
Is there any way to limit the results of a query on the "from" index before it
gets joined?
The SQL analogy might be...
SELECT *
from toIndex join
(select * from fromIndex
where "some query"
limit 1000
) fromIndex on fromIndex.from=toIndex.to
Example:
_query_:"{!join fromIndex=expressionData fr
d to buffer the query shape
>slightly; you didn't do this in your examples below. This is all a bit of
>a hack when using a field that internally is using floating point instead
>of fixed precision.
>
>~ David Smiley
>
>On 7/23/13 9:32 PM, "Kevin Stone" wrote:
ty slow if the amount of indexed data is really
>high.
>I'd love to hear how it works out for you. Your use-case would benefit a
>lot from an improved prefix tree implementation.
>
>I don't gather how a 3rd dimension would play into this. Support for
>multi-dimensional s
see what happens. I'm working (very slowly on very little spare time)
>on improving the PrefixTree implementations to scale to such large
>numbers;
>I hope something will be available this fall.
>
>~ David Smiley
>
>
>Kevin Stone wrote
>> I have a particular us
Thank you for the links, they really helped me understand. I see how the
spatial solution works now. I think this could work as a good backup if I
cannot get the custom field type working. The custom field would ideally be a
bit more robust than what I mentioned before, because a region really m
super(sources);
this.sf = sf;
}
@Override
public String name() {
return "point";
}
@Override
public String description() {
return name()+"("+sf.getName()+")";
}
I can try again this weekend to get a clean environment. However, the order I
did things in was the reverse of what you suggest. I got the
AbstractSubTypeFieldType error first. Then I removed my jar from the sharedLib
folder, and tried the war repacking solution. That is when I got
NoClassDefFo
I have a particular use case that I think might require a custom field type,
however I am having trouble getting the plugin to work.
My use case has to do with genetics data, and we are running into several
situations were we need to be able to query multiple regions of a chromosome
(or gene, or
ng, right? Bear in mind that these inserts happen
in threads that are pushing to Solr concurrently. So if 4.0 is logging
somewhere that 3.5 didn't, then the file-locking on that log file could be
slowing me down.
-Kevin
On 1/23/13 12:03 PM, "Kevin Stone" wrote:
>I'm sti
rints this
setting waitFlush=true.
These could be irrelevant, but thought I should add the information.
-Kevin
On 1/23/13 11:42 AM, "Kevin Stone" wrote:
>Do you mean commenting out the ... tag? Because
>that I already commented out. Or do I also need to remove the entire
> ta
11:21 AM, "Mark Miller" wrote:
>It's hard to guess, but I might start by looking at what the new
>UpdateLog is costing you. Take it's definition out of solrconfig.xml and
>try your test again. Then let's take it from there.
>
>- Mark
>
>On Jan 23, 20
I am having some difficulty migrating our solr indexing scripts from using 3.5
to solr 4.0. Notably, I am trying to track down why our performance in solr 4.0
is about 5-10 times slower when indexing documents. Querying is still quite
fast.
The code adds documents in groups of 1000, and adds e
13 matches
Mail list logo
