Re: More grist for the PostgreSQL vs MySQL mill

Поиск
Список
Период
Сортировка
От Shashank Tripathi
Тема Re: More grist for the PostgreSQL vs MySQL mill
Дата
Msg-id 7cab9c1b0701211830x54a37981t77a0c5ef5e91334b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: More grist for the PostgreSQL vs MySQL mill  ("Peter Rosenthal" <voiperster@gmail.com>)
Ответы Re: More grist for the PostgreSQL vs MySQL mill  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: More grist for the PostgreSQL vs MySQL mill  (Chris <dmagick@gmail.com>)
Re: More grist for the PostgreSQL vs MySQL mill  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-general
> select something from othertable;
> select * from table where table_id in (?, ?, ?, ?, ?, ?, ?, ...)


This is what MySQL's CEO Martin said in an interview on Slashdot. If
we can manage two queries as above through, say, a PHP application,
with each executing in 0.004 seconds, then an optimized subquery needs
to be beat the 0.008 mark to be a viable alternative.

This works for most people who're not looking for elegance of database
design. I am assuming MYISAM engine with indexes on the WHERE columns.
Granted, this is neither future nor fool proof, but in high traffic
environments, it is all worth the drop in elegance.

The problem is when the number of rows exceeds 30 million, MySQL
performance degrades substantially. For most people, this is not an
issue. PG is solid with huge databases, but in my experience, even the
most optimized subselect on PG will not return a value in 0.008
seconds  on 10 million rows -- I'd appreciate other experiences.

Shanx

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

Предыдущее
От: "Peter Rosenthal"
Дата:
Сообщение: Re: More grist for the PostgreSQL vs MySQL mill
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: documentation vs reality: template databases