It does much more sense :P Glad to learn about that option! thanks, Sebastien
On Fri, Jun 20, 2008 at 1:22 PM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: > Maybe autoCommit is a good option for you. In other words, don't let your > clients issue commits - have Solr commit every N docs or every N > minutes/hours. > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > ----- Original Message ---- > > From: Sébastien Rainville <[EMAIL PROTECTED]> > > To: solr-user <solr-user@lucene.apache.org> > > Sent: Friday, June 20, 2008 5:06:46 PM > > Subject: Reasonable number of updates before a commit > > > > Hi, > > > > Is there a rule of thumb for the maximum number of updates before issuing > a > > commit? > > > > For example, I'm using a MapReduce job for indexing a table in HBase... > but > > the problem is that I can't just let the reducers commit whenever they > want > > or else commits tend to happen at the same time and therefore resulting > in > > exceeding the maximum number of searchers warmed at the same time. On the > > other hand, I can't imagine updating let's say 2 000 000 records in the > > index in a distributed manner and issuing a commit only at the end... > > > > Sebastien > >
