Thanks Sergei, I think I'll look for that. I'll tell you all how it goes.
Cheers!
Le 21 nov. 2014 18:35, "Sergei Golubchik" a écrit :
> Hi, Pierre!
>
> On Nov 21, Pierre GOUPIL wrote:
> > That looks sweet, indeed. But my (quick) search doesn't give me a
tadir' on a ramdisk.
>
> http://en.wikipedia.org/wiki/RAM_drive
>
> A
>
>
>
> On 21 November 2014 05:30, Pierre GOUPIL wrote:
>
>> Good morning,
>>
>> Is there a way to have MariaDB run in-memory? I mean, without changing
>> the table engines.
&
wrote:
> Hi!
>
> On 21.11.14 06:30, Pierre GOUPIL wrote:
>
>> Good morning,
>>
>> Is there a way to have MariaDB run in-memory? I mean, without changing
>> the table engines.
>>
>> I have my production code which needs to be persisted to disk, but for my
Good morning,
Is there a way to have MariaDB run in-memory? I mean, without changing the
table engines.
I have my production code which needs to be persisted to disk, but for my
unit tests, it would be great to have an in-memory DB.
I'm in the Java world and I've tried HSQLDB but its SQL impleme
> And also it's worth noting that MariaDB-10.0 rebuilds both UNIQUE
> and non-UNIQUE indexes the fast way when you do ALTER TABLE ... ADD KEY.
Well this is a good news ! I'm going to give it a try.
Le 12/02/2014 15:45, Sergei Golubchik a écrit :
Hi, Pierre!
Okay, there
).
I'll do a bug report.
Le 12/02/2014 13:23, Sergey Vojtovich a écrit :
Hi Pierre,
there are quite a few MySQL bug reports in MySQL bug database that can
affect your use case. Like:
http://bugs.mysql.com/bug.php?id=5731
http://bugs.mysql.com/bug.php?id=29446
http://bugs.mysql.com/bug.php?id=
it should be documented.
Le 12/02/2014 11:15, Reindl Harald a écrit :
your keys *must* fit in the RAM, period
your key-buffers must be large enough
Am 12.02.2014 11:10, schrieb Pierre:
You don't undestand, I already did this. Read the thread since the beginning :
https://lists.launchpad.net/m
okudb and select for update, to
prevent race.
Sent from my iPhone
On Feb 12, 2014, at 12:49 AM, Pierre wrote:
Ok I understand, but this doesn't resolve the initialization problem, I'm sure
there is a bug, or something which can be improved a lot. I can't use the
UNIQUE con
t; Consider fronting your lookups with memcache (a hash index) or a bloom filter
(there are many
> implementations on the net) to reduce lookups.
>
> --Justin
Le 12/02/2014 09:04, Pierre a écrit :
Using this technique I have the same Issue. It's now running for severals
hours, I
unique index). So why
UNIQUE index is not behaving the same way ?
It's easy to reproduce the bug, just create a binary file of 2 or 3 x size of RAM, then load data
infile and try to create a UNIQUE index on it. It will never end.
>Am 10.02.2014 13:45, schrieb Pierre:
>> Mariadb is
Hello,
Mariadb is getting slower and slower when I'm inserting a massive amout of data. I'm trying to
insert 166 507 066 rows (12go) using load data infile '' into an empty table. I splitted my file in
13 parts of the same size because it was too long to insert in one shot. When I inserted more
11 matches
Mail list logo
