> On Sat, Mar 7, 2009 at 12:10 PM, wrote:
> Another way to find out whether this is the problem (yes, I know, you
> already answered this question ;-) is to set concurrent_insert=2 (see
> http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html ).
>
No go. Setting concurrent_insert=2 appea
> On Sat, Mar 7, 2009 at 12:10 PM, wrote:
Is there a way I can restore the concurrent select feature to a
working
state without having to shut down the server and rebuild the entire
data
base?
>>>
>>> Usually when concurrent insert is not permitted, it's because there
>>>
On Sat, Mar 7, 2009 at 12:10 PM, wrote:
>>> Is there a way I can restore the concurrent select feature to a working
>>> state without having to shut down the server and rebuild the entire data
>>> base?
>>
>> Usually when concurrent insert is not permitted, it's because there
>> are holes in the
>> Is there a way I can restore the concurrent select feature to a working
>> state without having to shut down the server and rebuild the entire data
>> base?
>
> Usually when concurrent insert is not permitted, it's because there
> are holes in the table that cause inserts to go somewhere other t
At 08:54 PM 3/5/2009, Baron Schwartz wrote:
> Is there a way I can restore the concurrent select feature to a working
> state without having to shut down the server and rebuild the entire data
> base?
Usually when concurrent insert is not permitted, it's because there
are holes in the table that
> Is there a way I can restore the concurrent select feature to a working
> state without having to shut down the server and rebuild the entire data
> base?
Usually when concurrent insert is not permitted, it's because there
are holes in the table that cause inserts to go somewhere other than
at t
> At 07:38 PM 2/25/2009, you wrote:
>
>> >
>> > not sure, though, feel free to report test results
>>
>>Results not good so far. I created a big load file by creating a list of
>>all the files on my server (using "find / -printf ...). and appending
>> that
>
> This bug was reported back in 2006 and
> At 07:38 PM 2/25/2009, you wrote:
>
>> >
>> > not sure, though, feel free to report test results
>>
>>Results not good so far. I created a big load file
>>Then I did a LOAD DATA CONCURRENT INFILE 'my_big_file'...
>>
>>While that was running, I ran a SELECT COUNT(*) query in another session.
>>The
At 07:38 PM 2/25/2009, you wrote:
>
> not sure, though, feel free to report test results
Results not good so far. I created a big load file by creating a list of
all the files on my server (using "find / -printf ...). and appending that
file four of five times over for several hundred thousand
>
> not sure, though, feel free to report test results
Results not good so far. I created a big load file by creating a list of
all the files on my server (using "find / -printf ...). and appending that
file four of five times over for several hundred thousand rows.
Then I did a LOAD DATA CONCUR
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
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
12 matches
Mail list logo
