Alan Tanaman wrote: > Agree about the performance degradation (estimated at 5-10% by Gospodnetic > et Hatcher), which only affects the indexing time, not the search time, but > we would put this as a clear caveat in the conf file. >
Note: this is just for the time-related degradation. Temporary space usage is 200% higher for compound indexes ... > We'd rather the incremental index process be a little slower (our big > performance problem is on parsing anyway), but that the file system work be > a little more manageable. > > Are there any objections? > I don't object to the idea of having this as an option, defaulting to non-compound index, with a clear comment in the config file about this tradeoff. -- Best regards, Andrzej Bialecki <>< ___. ___ ___ ___ _ _ __________________________________ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Nutch-developers mailing list Nutch-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nutch-developers
