yeah, I probably should have thought when I read that that if it was easy, it probably would have already been done! :)
Paul On 4 April 2014 11:07, Robert Muir <[email protected]> wrote: > Thank you Paul, I added some comments just so the technical challenges > and risks are clear. > > Its unfortunately not so easy to fix... > > On Thu, Apr 3, 2014 at 7:49 PM, Paul Smith <[email protected]> wrote: > > Thanks for the JIRA link Robert, I've added a comment to it just to share > > the real world aspect of what happened to us for background. > > > > > > On 1 April 2014 18:29, Robert Muir <[email protected]> > wrote: > >> > >> On Tue, Apr 1, 2014 at 2:41 AM, Paul Smith <[email protected]> > wrote: > >> > > >> > Thanks Robert for the reply, all of that sounds fairly hairy. I did > try > >> > a > >> > full optimize of the shard index using Luke, but the residual > >> > über-segment > >> > still has the filed definitions in it. Are saying in (1) that the > >> > creating > >> > of a new Shard index through a custom call to > IndexWriter.addIndexes(..) > >> > would produce a _fully_ optimized index without the fields, and that > is > >> > different than what an Optimize operation through ES would call? More > a > >> > technical question now on what the differences is between the Optimize > >> > call > >> > and a manual create-new-index-from-multiple-readers. (I actually > though > >> > that's what the Optimize does in practical terms, but there's > obviously > >> > more > >> > or less going on under the hood under these different code paths). > >> > > >> > We're going the reindex route for now, was just hoping there was some > >> > special trick we could do a little easier than the above. :) > >> > > >> > >> Optimize and normal merging don't "garbage collect" unused fields from > >> fieldinfos: > >> > >> https://issues.apache.org/jira/browse/LUCENE-1761 > >> > >> The addindexes trick is also a forced merge, but it decorates the > >> readers-to-be-merged: lying > >> and hiding the fields as if they don't exist. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "elasticsearch" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/elasticsearch/CAMUKNZW2-FEjA6CChSR3%2Br0GQYAfJ9ZOOhyU565V79QMTrPFWQ%40mail.gmail.com > . > >> > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/elasticsearch/CAHfYWB5dHJ70cxzZuZ21gdeQwN1ckZ40Yu4K%2BmJYexK-i01AVQ%40mail.gmail.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAMUKNZW6bH_M5qcf0qnRUKxvm%3DVjMdLO7RAxCbeWsKMN%3DjDrqA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHfYWB4wQ%3D5u9%2BWU6kiA4LRiDrHNak5_qsFpVs5E5ziNDH1v%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
