Re: Probable faq: need some benchmarks of pgsql vr.s mysql
От | MARK CALLAGHAN |
---|---|
Тема | Re: Probable faq: need some benchmarks of pgsql vr.s mysql |
Дата | |
Msg-id | AANLkTimq718qCu=LzEdVQxe0tey7Hm+KZeH4dXXSfkuz@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Probable faq: need some benchmarks of pgsql vr.s mysql (Brian Hurt <bhurt@spnz.org>) |
Список | pgsql-advocacy |
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
В списке pgsql-advocacy по дате отправления: