> 1. With the batch insert code turned on there are a number of regression > tests > that fail. They must all pass without errors prior to production release. > Responsible: Eric > Deadline: Roughly the end of March
Makes sense. > - First, have a default limit of the number of records that will be > inserted > in any one batch request. This should guarantee that an out of memory > problem will not normally occur. Can we calculate this based on available memory at execution time? General tuning wisdom for the commercial databases (DB/2, Oracle, etc) target about 60% of real memory as the goal for this kind of segmentation. That allows some query optimization overhead, and a little wiggle room if the optimizer guesses wrong. > - Second, add a new directive to the Catalog resource that allows the user > to > change the default batch size (by setting the value to 0 or very large, > you > can effectively allow the batch to be arbitrarily large). Makes sense. > - Third (this is optional, but very desirable), implement a new directive > that > allows the user to enable/disable the batch insert mechanism. This would > require a bit of change in the subroutine names in the cats directory so > that > we can enable the new code and the old code at the same time, but select > which is used at runtime for each DB based on the directive value. If the > first and second items are implemented, the batch insert would be enabled > by > default, otherwise it will be turned off. > Responsiblity for above 3 (4) points: Eric (and possibly Marc) > Deadline: rougly the end of March OK. If the new algorithm really works better, it seems like extra work that might not be needed, but c'est la vie. > > 3. Documentation > Before putting this into production, I would like to see a bit more > documentation about the new algorithms -- this is documentation that would > be > placed in the code. Marc has offerred to answer questions and write some > documentation, I offer to integrate it into the code, and continue to ask > questions until it is clear. This item should be no problem to resolve. > Responsible: Kern + Marc (with help from Eric if he wants) > Deadline: Kern understands the algorthm by mid April. Works for me. Analyzing this for race conditions will be really interesting, I think. In fact, I think it'll be a really good final exam question for my informatics students...*evil grin* Thanks, guys! ------------------------------------------------------------------------- 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 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users