maria-discuss team mailing list archive

[Sergey Petrunia <sergey@xxxxxxxxxxx>]

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/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