Re: Postgres performance
От | Ian Barwick |
---|---|
Тема | Re: Postgres performance |
Дата | |
Msg-id | 1d581afe05030215351ad80622@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres performance (Scott Marlowe <smarlowe@g2switchworks.com>) |
Список | pgsql-sql |
On Wed, 02 Mar 2005 09:00:14 -0600, Scott Marlowe <smarlowe@g2switchworks.com> wrote: (...) > The reason PostgreSQL is slower is because it (and by extension the team > behind it) cares about your data. > > Here's a list of the things MySQL will gladly do wrong: > > http://sql-info.de/mysql/gotchas.html Leaving MySQL or other databases out of the equation for the moment: the above site is a purely dynamic website (i.e. no static files, not even images) driven by a PostgreSQL backend. There are several issues with the underlying application (a DIY hack job ;-) which mean it isn't as fast as it could be. However, although I haven't been able to run comparisions with other RDBMSs I find it hard to imagine where significant speed gains could be made at the database end, especially if stored procedures are not available (any raw speed increase could well be eaten up by the need to implement several critical functions in the application). Recently I added a function (for another site on the same server, running from the same database) to generate a blog-style calendar for a given month to show on which days an article was written. Despite involving a three-table join with a longish list of join conditions it proved to be jaw-droppingly fast (a few milliseconds, fast enough not to have to cache the result anywhere, which is what I was originally expecting to have to do) and as an added bonus returns the weekday expressed as an integer, so all the application has to do is a little formatting to produce the end result. I've also run a PostgreSQL-based multi-thousand page site (with a simpler structure) without any complaints speedwise; and when one of the disks died very nastily during an intensive write operation (software raid on dodgy hardware) I was even able to rsync the database files direct from the surviving disk over to a backup server and restart PostgreSQL there straight off, without any evident problems. (Disclaimer: it was an emergency, and the data was non-critical; nevertheless I never found any evidence of corruption). Ian Barwick
В списке pgsql-sql по дате отправления: