Roberto Cornacchia wrote: > 2. The restore is almost unusable for large databases, as it is > extremely slow. I suspect the main reasons being: > - COPY INTO .. FROM STDIN (used in the dump) is much much slower than > copying from a file, regardless of whether the number or record to copy > is given or not.
It seems that a configuration option added to msqldump to 'split' output could just fix that. > - Column constraints, as primary key, not null, etc, are issued upon > table creation, before the COPY INTO, rather than being postponed with > an ALTER TABLE after the copy (FOREIGN KEYS are instead postponed to the > end of the script). I am looking at this now I agree with you that this could help a lot. Will need to move some stuff around because of the -D option that (imho) should inline everything. Stefan ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Monetdb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
