Yes commits are very expensive and optimizes are even expensive. Coming to your question of numdocs and 0's in update handler section The numdocs that u see on top are the ones that are committed. The ones u see below are the ones u have updated, not committed. update handlers ==============commits : 0 In the particular server session, how many commits have u doneautocommits : 0 optimizes : 0 In the particular server session, how many commits have u donedocsPending : 0 In the particular server session, how many Documents are pending commit/optimize. For the size of 10, commit of optimize wudnt really make an impact. The general tendency is to commit/optimize from within the app, which is not right. auto committing is the way to go and like fuad said, committing nightly is the right way to do it IMO too.
> Date: Thu, 7 Aug 2008 15:13:18 -0700> From: [EMAIL PROTECTED]> To: > solr-user@lucene.apache.org> Subject: Re: How do I configure commit to run > after updates> > > Okay... so this all makes sense, and I can sorta make it > work, however,> > the commit is never run by itself when the index is > updated. I have to> > manually call the commit script from the command line > to get it to happen.> > Jacob, 'commit' is expensive (you will loose SOLR > caches, and etc.)... > 'commit' and 'optimize' should be called only once per > thousands > (hundreds of thousands, etc.) updates... I run it only once a > day. You > can run it explicitly after each update if you do not have > > millions-a-day updates...> > ===> http://www.tokenizer.org - faceted search> > > _________________________________________________________________ Searching for the best deals on travel? Visit MSN Travel. http://msn.coxandkings.co.in/cnk/cnk.do
