maria-discuss team mailing list archive
-
maria-discuss team
-
Mailing list archive
-
Message #04783
Re: question about fast path for TRUNCATE TABLE
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 <sergey@xxxxxxxxxxx> 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
>
>
>
Follow ups
References