Re: speed on Postgresql compared to Mysql

Поиск
Список
Период
Сортировка
От Joel Burton
Тема Re: speed on Postgresql compared to Mysql
Дата
Msg-id Pine.LNX.4.21.0104091115520.1350-100000@olympus.scw.org
обсуждение исходный текст
Ответ на Re: speed on Postgresql compared to Mysql  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-general
On Mon, 9 Apr 2001, Lincoln Yeoh wrote:

> At 05:30 AM 08-04-2001 -0400, Joel Burton wrote:
> >On Tue, 3 Apr 2001, Livio Righetti wrote:
> >> Also we used Postgresql for Radius (authentication) et we have to make 3
> >> vacuum per day otherwise the first server is overload and the user go to
> the
> >> backup server.
> >>
> >> Is it normal or my Postgresql is not well configured ?
> >
> >Err, yes.
> >
> >Did you just do 40,000 inserts in a row, one after another? Realistic
> >speed tests often have many requests coming in together, to simulate
> >application- and web-usage.
> >
> >In addition, did you wrap this in a transaction? Otherwise, you're
> >performing one transaction for *every single* insert, which is much slower
> >than in a a transaction.
> >
> >(Generally speaking, if you want to just add 40,000 rows to a table, I'd
> >use COPY, not INSERT ;-) )
>
> I don't think COPY is useful or relevant in a normal ISP authentication
> logging scenario.
>
> Wrapping more than one insert doesn't help either. I think you would
> normally want to commit each customer's transaction individually.
>
> >From his figures he can sustain about 136 inserts a second. Is that good
> enough for peak loads at a medium to big ISP?

Well, I confess I was being a bit facetious. No, COPY isn't generally
useful web apps, and, in many cases, you would handle each transaction
separately.

However, scheduling 40,000 INSERTs, all neatly following one after
another, and measuring how long that takes isn't very realistic
either! :-)

136 of anything a second seems good to me -- unless one is tracking micro
things, like all TCP/IP requests made by all users at an ISP. Given the
inexpensive price of hardware and the expensive cost of programmer time,
it usually seems better to throw some money at 512MB, 7200RPM SCSI drives
and such, rather that at paying a technologist to code in lots of
Perl/PHP/Python/Pwhatever to build all the stuff into your web app that
MySQL can't do for you.


--
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington


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

Предыдущее
От: Scott Gritton
Дата:
Сообщение: RE: Convert Filemaker Pro db to Postgresql db
Следующее
От: Michelle Murrain
Дата:
Сообщение: Re: RE: Convert Filemaker Pro db to Postgresql db