From: sasha
Date: November 23 2000 7:46pm
Subject: Re: Speedup inserts that involve updating fulltext index
List-Archive: http://lists.mysql.com/internals/151
Message-Id: <3A1D740E.C8502812@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Loic Dachary wrote:
> 
> Sergei Golubchik writes:
>  >
>  > Ok, I cannot say that much. I didn't ever look at INSERT DELAYED before,
>  > but when I did, after your mail, looks that it's ideally suited for grouping
>  > fulltext index updates (it's better then hooking on selects).
> 
>  Glad that you see it as a good idea.
> 
>  > But delayed_insert::handle_inserts calls mi_write to modify table files.
>  > So there should be some way to tell mi_write not to create keys for
>  > row data (probably, via mi_extra() call ?).
> 
>  mi_extra seems exactly fit for that purpose thanks.
> 
>  > And how will you tell find_all_keys which are "previously inserted records" ?
> 
>  The idea is to write another function that behaves mostly like find_all_keys
> except it gets rows from the delayed insert cache instead. This function would
> be called *after* the rows are inserted.
> 
>  > >        It occurs to me that we might as well do the same for all the indexes
>  > > types, no need to be selfish :-)
>  >
>  > Yes, but it's most important for fulltext keys, as quite a few rows can
>  > produce a lot of fulltext index entries.
> 
>  Yes, anyway I'll only focus on fulltext keys for now, no need to accumulate
> problems.
> 
>  Do you think it's a good idea to cc: this discussion to
> internals@stripped or will this be considered noise ?

Yes, I think it is a good idea - this is exactly what internals list is for!

-- 
MySQL Development Team
   __  ___     ___ ____  __ 
  /  |/  /_ __/ __/ __ \/ /   Sasha Pachev <sasha@stripped>
 / /|_/ / // /\ \/ /_/ / /__  MySQL AB, http://www.mysql.com/
/_/  /_/\_, /___/\___\_\___/  Provo, Utah, USA
       <___/