Subject: Re: PostgreSQL
To: Curt Sampson <cjs@cynic.net>
From: Greg 'groggy' Lehey <grog@NetBSD.org>
List: tech-perform
Date: 02/02/2006 11:30:18
--2+N3zU4ZlskbnZaJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thursday,  2 February 2006 at  9:43:50 +0900, Curt Sampson wrote:
> On Thu, 2 Feb 2006, Marcin Jessa wrote:
>
>> I was wondering if any of you have experience with PostgreSQL's
>> performance on NetBSD 3.0 or CURRENT compared to other open source
>> O.S's.
>
> I have been using PostgreSQL extensively on NetBSD since 7.3. I don't
> have much comparison data, but what I do have indicates that performance
> is roughly the same across NetBSD, FreeBSD and Linux, assuming similar
> hardware and configuration. This isn't surprising since PostgreSQL
> doesn't actually use much in the way of sophisticated services from the
> OS. The most important thing would be the filesystem code.

I don't know PostgreSQL; does it use threads?

> Unless your database is very small (i.e., only a few GB) database, by
> far the most important factor in performance will be the configuration
> of your disk storage system and how you design your schema and queries.
> The OS won't make anywhere near as much difference as either of those.
>
>> What threading model will be used
>
> PostgreSQL does not use threads; it uses a separate process for each
> connection. So how well or poorly the OS performs with threads is
> irrelevant.

MySQL does, and this seems to be the problem with MySQL 5/FreeBSD 6.
The performance hit comes with many concurrent requests.  The
difficulties splitting threads of one process across multiple
processors probably also make a difference.

Of course, separate processes have their own issues.  But they need to
be measured certainly.

> BTW, it's best, if you're looking at PostgreSQL, not even to
> consider data about MySQL's comparative performance on different
> OSes. MySQL is a completely different animal--it's not in fact a
> real DBMS at all, but more a dumb data storage system that can be
> queried with SQL. So the underlying techniques it uses can be quite
> different.

I think that your information here is out of date.  This was once the
case, but what "real DB" features are you missing in MySQL 5.0?

Greg
--
See complete headers for address and phone numbers.

--2+N3zU4ZlskbnZaJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQFD4VmiIubykFB6QiMRAtEyAKCUQc0EFYMze4r8uEfiwVi+qgmL7ACeKgG7
R1Fgl2eTnwtK15ASXF8n7zc=
=elOR
-----END PGP SIGNATURE-----

--2+N3zU4ZlskbnZaJ--