I know this doesn't answer any of your questions directly, but I imagine that if you run the load data on the insert table of the merge set, the rest might still be available for operations through the actual merge alias.
not sure, though, feel free to report test results :-) On Wed, Feb 25, 2009 at 4:35 AM, <buf...@biffco.net> wrote: > I'm working on a system that uses merged tables with insert method LAST, > and occasionally the application runs a LOAD DATA INFILE with a pretty big > input data set. During the load data, other users running selects are > blocked. > > As it stands at this time, some of the constituent merged tables in the > merge set have deleted rows (i.e., "holes"). > > I read in the documentation > (http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html) that > concurrent selects are permitted during a LOAD DATA INFILE if the free > space is first defragmented, but it doesn't specifically address the > situation of merged tables. > > Provided I have run OPTIMIZE TABLES, should I expect a multi-user > application to successfully perform concurrent selects while the lengthy > load data statement is running? > > And furthermore, assuming one or more of the constituent tables has free > space (i.e., "holes"), do I need to run OPTIMIZE TABLES on each > constituent file of the merge set separately, or do I run it on the > defined merge table? > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be > > -- Celsius is based on water temperature. Fahrenheit is based on alcohol temperature. Ergo, Fahrenheit is better than Celsius. QED. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
