Hi Sergey, Yes, it was partitioned as mentioned in the other issue (Actually same structure as the one described for the LOAD DATA)
-GL 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 > partitioned > table? (or it was non-partitioned?) > > 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
