← Back to team overview

maria-discuss team mailing list archive

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