Re: more anti-postgresql FUD

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: more anti-postgresql FUD
Дата
Msg-id 20061011014310.GE72517@nasby.net
обсуждение исходный текст
Ответ на Re: more anti-postgresql FUD  (Jorge Godoy <jgodoy@gmail.com>)
Ответы Re: more anti-postgresql FUD  ("Dawid Kuroczko" <qnex42@gmail.com>)
Список pgsql-general
On Tue, Oct 10, 2006 at 06:25:21PM -0300, Jorge Godoy wrote:
> "Jacob Coby" <jcoby@listingbook.com> writes:
>
> > We were looking to improve our session performance, so I did a basic
> > test of using mysql 4.0 innodb vs postgres 8.1.  The test did a simple
> > retrieve, update, save; 1 time per page.  mysql was stock, pg had a
> > shared_buffers and a couple of other standard tweaks done.  ab was used
> > to provide the load.  server was an old dell pe2450 with 640mb of ram.
> > tables were simple and a single primary key-foreign key relationship
> > between them.
> >
> > pg was not only faster, it scaled to higher concurrency and had more
> > predictable response times.  mysql nosed over at around 5 concurrent
> > connections.  pg went to somewhere around 15.
> >
> > the more I read, the more it seems that mysql speed is a myth.  it may
> > be faster for simple flat-text sort of operations with one or two
> > concurrent users where the app maintains RI, validates all data, and
> > handles all of the complex joins.  it just doesn't seem to scale up as
> > well as pg.
>
> I'm sorry but you tuned PG and not MySQL.  This by itself makes that claim a
> problem.  If you used PG stock versys MySQL stock, then it would be more
> valid.  When comparing two things you have to give them the most fair
> condition that is possible (i.e., either put two experts to tune both or use
> both as shipped by their suppliers).

Not necessarily. Last I heard, MySQL ships with multiple config files,
ie: small, medium and large. So by choosing one of those you're
effectively tuning MySQL as well.

If you want a real apples-apples out-of-the-box, run MySQL with a small
config and PostgreSQL stock.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

В списке pgsql-general по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Problem with a date when restoring on postgresql 7.4.9 : date/time field value out of range
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: restoring a file system backed-up data dir