Yes, it was partitioned as mentioned in the other issue (Actually same
structure as the one described for the LOAD DATA)
Le dim. 6 août 2017 à 20:39, Sergey Petrunia <ser...@mariadb.com> a écrit :
> On Fri, Aug 04, 2017 at 01:41:42PM +0000, Guillaume Lefranc wrote:
> > 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.
> I've tried again and I observe the following:
> - TRUNCATE TABLE non_partitioned_table works instantly
> - TRUNCATE TABLE partitioned_table is slow.
> This is in both MariaDB and facebook/mysql-5.6.
> I'll collect the details and report a bug.
> Guillaume, could it be that you saw TRUNCATE TABLE being slow on a
> table? (or it was non-partitioned?)
> Sergei Petrunia, Software Developer
> MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
Mailing list: https://launchpad.net/~maria-discuss
Post to : email@example.com
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp