* Curt Sampson <cjs@cynic.net> [060201 16:45] 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.
> 
> 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.

There is one important thing that FreeBSD has, I am unsure if NetBSD
has it, but someone may want to chime in and let me know if it does.

Basically, FreeBSD has a setting 'kern.ipc.shm_use_phys' under sysctl
that will tell the kernel not to make SysV shared memory pageable.  This
is VERY handy when you are going to use very large shared segments.  Solaris
does this by default, on FreeBSD you need to enable it like so:

sysctl kern.ipc.shm_use_phys=1

Before starting postgresql.

> 
> >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.
> 
> 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.

You are very correct here.  MySQL is not a "real database", it's close,
but it just doesn't offer all the cool features that Postgresql offers.

The funny part is that for high performance stuff you're going to have
to come up with a "caching layer" over the database anyhow, so selecting
simply based on a raw speed is a bad idea.  I love postgres, I abhor
mysql, it just stinks.

> 
> Note that this was a bit heavily cross-posted; I've redirected responses
> to tech-perform.

Thanks. :)

And good luck!

-- 
- Alfred Perlstein