> No. the options for the DBA should be kept to a minimum. > Go for the solution that will work for the next few years. > Trunk users at some point should migrate through dump/restore, > which can be used for passwords refresh requirements as well.
Be careful with relying on dump/restore. 1. The dump is correct only if you do it as user monetdb, but not if you do it as a normal user (see bug #2782202) 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. - 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). Roberto -- | M.Sc. Roberto Cornacchia | CWI (Centrum voor Wiskunde en Informatica) | Science Park 123, 1098XG Amsterdam, The Netherlands | tel: +31 20 592 4322 , http://www.cwi.nl/~roberto ------------------------------------------------------------------------------ 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
