On Aug 30, 2007, at 11:37 PM, Walter Underwood wrote:
Sorry dude, I'm pining for Python and coding in Java. --wunder
No need to be sorry well, unless you do really enjoy forced
whitespace and __init__ ugliness. :)
Why don't we tie in scripting engine support into Solr via BSF or the
Only if you think the rest of Solr would be better written in JRuby too!
> -Original Message-
> From: Erik Hatcher [mailto:[EMAIL PROTECTED]
> Sent: 31 August 2007 02:57
> To: solr-user@lucene.apache.org
> Subject: Re: performance questions
>
>
> On Aug 30
Sorry dude, I'm pining for Python and coding in Java. --wunder
On 8/30/07 6:57 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote:
>
> On Aug 30, 2007, at 6:31 PM, Mike Klaas wrote:
>> Another reason why people use stored procs is to prevent multiple
>> round-trips in a multi-stage query operation. T
On Aug 30, 2007, at 6:31 PM, Mike Klaas wrote:
Another reason why people use stored procs is to prevent multiple
round-trips in a multi-stage query operation. This is exactly what
complex RequestHandlers do (and the equivalent to a custom stored
proc would be writing your own handler).
A
On 30-Aug-07, at 3:18 PM, Chris Hostetter wrote:
2. Someone asked me if SOLR utilizes anything like a "stored
procedure" to make queries faster. Does SOLR support anything
such as this?
it's kind of an apples vs orange-juice comparison, ut typcailly
when people talk about DB stored pr
2. Someone asked me if SOLR utilizes anything like a "stored procedure"
to make queries faster. Does SOLR support anything such as this?
it's kind of an apples vs orange-juice comparison, ut typcailly when
people talk about DB stored procedures being faster then raw SQL they are
refering to
On 30-Aug-07, at 9:51 AM, Andrew Nagy wrote:
Here are a few SOLR performance questions:
1. I have noticed with 500,000+ records that my facets run quite
fast regarding my dataset when there is a large number of matches,
but on a small result set (say 10 - 50) the facet queries become
ver
