Re: Probable faq: need some benchmarks of pgsql vr.s mysql - Mailing list pgsql-advocacy

From Brian Hurt
Subject Re: Probable faq: need some benchmarks of pgsql vr.s mysql
Date
Msg-id alpine.DEB.2.00.1010301943240.31170@sergyar
Whole thread Raw
In response to Re: Probable faq: need some benchmarks of pgsql vr.s mysql  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: Probable faq: need some benchmarks of pgsql vr.s mysql  (MARK CALLAGHAN <mdcallag@gmail.com>)
List pgsql-advocacy

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


pgsql-advocacy by date:

Previous
From: Robert Treat
Date:
Subject: Re: Probable faq: need some benchmarks of pgsql vr.s mysql
Next
From: Guillaume Lelarge
Date:
Subject: Re: Tasks for the Google Code-In