maria-discuss team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

MyRocks stores data in RocksDB column families and they can be shared by
indexes/tables. So TRUNCATE TABLE, DROP TABLE, DROP DATABASE don't unlink
files. The benefit is that they are very fast. The cost is that it can take
time to reclaim space as that is done in the background when compaction
runs. And there are ways to get compaction running earlier than normal to
get space reclaimed.

But the problem in this case is that slowness appeared to be from using
"delete 1 row at a time" algorithm for TRUNCATE. I can't reproduce that in
FB MySQL, but some of the code in MariaDB that determines wether to use
"delete 1 row at a time" differs from what we have in FB MySQL and I have
more details on that at
https://groups.google.com/forum/#!topic/myrocks-dev/dhweTwN-9xg

On Fri, Aug 4, 2017 at 6:41 AM, Guillaume Lefranc <guillaume@xxxxxxxxxxxx>
wrote:

> Hi Sergey,
>
> I might be able to try again, though I moved to a different database at
> this point.
> But the phenomenon I observed was very high IO for several hours, and the
> table was still not dropped and recreated.
> if TRUNCATE TABLE just unlinks the data files we shouldn't observe that
> behavior.
>
> Thanks
> Guillaume
>
> Le dim. 9 juil. 2017 à 22:34, Sergey Petrunia <sergey@xxxxxxxxxxx> a
> écrit :
>
>> Hello,
>>
>> On Fri, Jun 30, 2017 at 08:58:08AM -0700, MARK CALLAGHAN wrote:
>> > This started as a question on a MyRocks list. MyRocks comes from
>> MariaDB in
>> > this case and the code that determines whether the truncate table fast
>> path
>> > is used looks different in MariaDB than in FB MySQL. By "fast path" for
>> > truncate I mean the use of drop/recreate for truncate. The slow path is
>> > delete one row at a time. In this case, truncate is doing delete one
>> row at
>> > a time for MyRocks in MariaDB but drop/recreate in FB MySQL.
>> >
>> > https://groups.google.com/forum/#!topic/myrocks-dev/dhweTwN-9xg
>>
>> I didn't try to measure speed, but when I debugged TRUNCATE statements in
>> MariaDB and MySQL, I see they both call ha_rocksdb::create(), which
>> re-creates
>> the table.
>>
>> MariaDB 10.2: https://gist.github.com/spetrunia/
>> 35738308469e27381056c6e90a5e2ce6
>> FB/MySQL-5.6
>> <https://gist.github.com/spetrunia/35738308469e27381056c6e90a5e2ce6FB/MySQL-5.6>:
>> https://gist.github.com/spetrunia/18096aa8ec965dc37a502496217c0bb0
>>
>> MariaDB also prints these statements into stderr
>>
>> 2017-07-08  2:53:10 140737294370560 [Note] RocksDB: Begin filtering
>> dropped index (0,261)
>> 2017-07-08  2:53:10 140736961083136 [Note] RocksDB: Finished filtering
>> dropped index (0,261)
>>
>> which is another indication that there is no row-by-row deletion.
>>
>> I was using current github trees of both FB/mysql-5.6 and MariaDB-10.2.
>> Maybe
>> that is the reason... I'll do more checks.
>>
>>
>> BR
>>  Sergei
>> --
>> Sergei Petrunia, Software Developer
>> MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~maria-discuss
>> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help   : https://help.launchpad.net/ListHelp
>>
>


-- 
Mark Callaghan
mdcallag@xxxxxxxxx