I don't really like that name, for the same reason ("create" and "new"
imply that an entirely new reader is being created, which is far more
costly than what normally happens).Mike On Tue, Nov 24, 2009 at 5:02 AM, Uwe Schindler <[email protected]> wrote: > How about newReader()? > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > >> -----Original Message----- >> From: Michael McCandless [mailto:[email protected]] >> Sent: Tuesday, November 24, 2009 11:00 AM >> To: [email protected] >> Subject: Re: Searching while optimizing >> >> On Tue, Nov 24, 2009 at 1:44 AM, vsevel <[email protected]> wrote: >> > >> > 1) correct: I am using IndexWriter.getReader(). I guess I was assuming >> that >> > was a privately owned object and I had no business dealing with its >> > lifecycle. the api would be clearer to rename the operation >> createReader(). >> >> I just committed an addition to the javadocs that the caller is >> responsible for closing the returned reader. >> >> I think createReader() isn't great either because it sound more >> expensive than it is -- under the hood, the returned reader is >> typically sharing many subreaders with the last reader obtained. That >> sharing is what makes the reopen time fast. >> >> > 2) how much transient disk space should I expect? isn't this pretty much >> > what the index writer javadoc said we should not do: "When running in >> this >> > mode, be careful not to refresh your readers while optimize or segment >> > merges are taking place as this can tie up substantial disk space." >> >> It is exactly what the javadoc says you should not do, but if you know >> the risks, go for it ;) >> >> How much space is tied up depends on how often you reopen and how >> quickly you close the last reader. If eg you aggressively close the >> last reader, such that effectively only one reader is open at once, >> then I think you're looking at worst case index consumes 4X it's >> "nominal" size (vs 3X if you don't open a single reader). >> >> Mike >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
