From: Ian Barwick <barwick@gmail.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: mauro <bertolima@yahoo.it>
Cc: pgsql-sql@postgresql.org
Subject: Re: Postgres performance
Date: Thu, 3 Mar 2005 00:35:19 +0100
Message-ID: <1d581afe05030215351ad80622@mail.gmail.com> (raw)
In-Reply-To: <1109775613.30529.359.camel@state.g2switchworks.com>
References: <d64dda1e.0502230229.3deaf864@posting.google.com>
<421D8ABC.2030601@archonet.com>
<d64dda1e.0503010252.67c2312d@posting.google.com>
<1109775613.30529.359.camel@state.g2switchworks.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: barwick@gmail.com, smarlowe@g2switchworks.com, bertolima@yahoo.it
Subject: Re: Postgres performance
In-Reply-To: <1d581afe05030215351ad80622@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox