PostgreSQL Performance - Re: Decide between Postgresql and Mysql (help of

Author

Re: Decide between Postgresql and Mysql (help of

Marcos

2006-03-28, 8:29 pm

> So, what exactly are you planning on doing?

The application will be a chat for web, the chats will be stored in the
server. In a determined interval of time... more or less 2 seconds, the
application will be looking for new messages.

I believe that it will make many accesses. The write in disc will be
constant.

Thanks :o)

Marcos

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Chris Travers

2006-03-28, 8:29 pm

Marcos wrote:

>
>The application will be a chat for web, the chats will be stored in the
>server. In a determined interval of time... more or less 2 seconds, the
>application will be looking for new messages.
>
>I believe that it will make many accesses. The write in disc will be
>constant.
>
>
Ok. I would favor PostgreSQL for reasons of ease of future
development. However, lets look at what both RDBMS's buy you:

MySQL:
1) Possibility of many components for web apps that can be used though
the lack of certain features (such as complex updateable views) makes
this possibly an issue.
2) Great simple read performance.

PostgreSQL:
1) Possibility to integrate any other components later (including those
on MySQL via DBI-Link).
2) Fabulous community support (and I am sure fabulous paid support too
given the fact that many of those who contribute to the great community
support also offer paid support).
3) Better parallel write performance.
4) Greater extensibility, leading to greater flexibility down the road
should you want to add in new components without rewriting your front-end.

For a simple chat client, you can probably put something together with
some Perl/CGI scripts, Jabber, and MySQL or PostgreSQL pretty easily and
without much development labor at all. Indeed I would suggest that the
RDBMS is, absent other specific concerns, the least of your issues.

In other words, both are probably adequate. It is impossible to provide
an estimate for capacity though without knowing the app in question,
expected query composition, and so forth.

Best Wishes,
Chris Travers
Metatron Technology Consulting

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

PFC

2006-03-28, 8:29 pm

>
> The application will be a chat for web, the chats will be stored in the
> server. In a determined interval of time... more or less 2 seconds, the
> application will be looking for new messages.
>
> I believe that it will make many accesses. The write in disc will be
> constant.

Ah, cool. That's exactly what a database is not designed for xD

Try this, I coded this in about 1 hour as a joke last week.
http://peufeu.com/demos/xhchat/
It works in firefox and opera, uses xmlhttprequest, and the messages are
stored in a dbm database.

We have also coded a real HTTP chat. I'll briefly expose the details
on-list, but if you want the gory stuff, ask privately.

There is a Postgres database for users, authentication, chatrooms and
stuff. This database can be modified by a full-blown web application.
Of course, messages are not stored in the database. It would be suicidal
performance-wise to do so.

An asynchronous HTTP server, using select() (lighttpd style) is coded in
Python. It is very special-purpose server. It keeps an open connection
with the client (browser) and sends messages as they arrive in the
chatroom, with no delay. The connection is interrupted only when the
client submits a new message via a form, but this is not mandatory.

My memories are a bit old, but we benchmarked it at about 4000
messages/second on a low-end server (athlon something). Concurrent
connections are unlimited. Disk I/O is zero. I like it.
If you store messages in the database, you can hope to be about 10-50
times slower.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Vivek Khera

2006-03-29, 11:31 am

On Mar 28, 2006, at 11:55 AM, Marcos wrote:

> The application will be a chat for web, the chats will be stored in
> the
> server. In a determined interval of time... more or less 2 seconds,
> the
> application will be looking for new messages.

We bought software for this purpose (phplive). It is based on mysql
using isam tables and is written in (surprise!) php. Two of my
"favorite" techonologies! :-)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Sponsored Links