Re: performance questions
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 javax extension methods? What about the new release of jython? Erik 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. This is exactly what complex RequestHandlers do (and the equivalent to a custom stored proc would be writing your own handler). And we should be writing those handlers in JRuby ;) Who's with me? Erik
RE: performance questions
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, 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). And we should be writing those handlers in JRuby ;) Who's with me? Erik
Re: performance questions
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 procedures being faster then raw SQL they are refering tohte fact that the SQL in the stored proc is compiled only once, and a query plan is produced which is then reused each time the proc is called with various inputs. in that regard no, Solr does not have any equivilent functinality. the query parser that compiles string input into Query objects to execute does not save existing Query structures for reuse with different input values. the Query=DocSet mappings from previous queries are cached and reused however ... so two people searching for hte exact same thing without any index modifications between them will result in the second person getting very fast performance ... i don't know of any DB that has anything like that. Solr's ability to autowarm recent queies when doing a commit is also something i've never heard of any type of DB doing. Modern SQL DBs have (typically small) query caches that function similarly to Solr's query/document cache, and row-level caches that function similarly to the OS disk cache in Solr. Though I don't know if there is anything quite like filter caches in most DBs. 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). -Mike
Re: performance questions
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. This is exactly what complex RequestHandlers do (and the equivalent to a custom stored proc would be writing your own handler). And we should be writing those handlers in JRuby ;) Who's with me? Erik
