The "insert buffer" in InnoDB accelerates this workload. It buffers
changes in a special b-tree to avoid disk IO during secondary index
maintenance. For my workloads the special b-tree is able to capture
multiple changes to blocks and is likely reduce the IO requirements
for the application. Even without that benefit it allows the server to
absorb workload spikes as the disk reads for secondary index
maintenance are deferred.
This is done for inserts in MySQL 5.1 and for inserts, updates and
deletes in MySQL 5.5. This won't allow InnoDB to match TokuDB in
performance, but it should provide much better throughput than you
would expect from an engine that does update in place.
http://www.google.com/search?hl=en&q=insert+buffer+innodb
On Sat, Oct 30, 2010 at 4:44 PM, Brian Hurt <bhurt@spnz.org> wrote:
>
>
> On Sat, 30 Oct 2010, Stefan Kaltenbrunner wrote:
>
>> On 10/29/2010 11:37 PM, Brian Hurt wrote:
>>>
>>> For the record, the table we're having trouble inserting into is ~100
>>> rows with ~50 indexes on it. E.F Codd is spinning in his grave. The
>>> reason they went with this design (instead of one that has two tables,
>>> each with 3-6 columns, and about that many indexes) is that "joins are
>>> slow". Which they may be on Mysql, I don't know. But this is
>>> (unfortunately) a different battle.
>>
>> is that really only 100 rows or are you actually talking about columns?
>
> Bleh, I meant columns.
>
> 100 rows is nothing.
>
>> if the later you will have a very hard time getting reasonable bulk/mass
>> loading performance in most databases (and also pg) - a table that wide and
>> with a that ridiculous number of indexes is just bound to be slow. Now I
>> actually think that the figures you are getting from innodb are fairly
>> reasonable...
>>
>>
>> Stefan
>>
>
> Brian
>
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>
--
Mark Callaghan
mdcallag@gmail.com
