Re: Re: Red Hat to support PostgreSQL - Mailing list pgsql-general

From Philip Molter
Subject Re: Re: Red Hat to support PostgreSQL
Date
Msg-id 20010627221152.M12723@datafoundry.net
Whole thread Raw
In response to Re: Re: Red Hat to support PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Re: Red Hat to support PostgreSQL  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: Red Hat to support PostgreSQL  (Alex Pilosov <alex@pilosoft.com>)
List pgsql-general
On Wed, Jun 27, 2001 at 06:58:18PM -0400, Bruce Momjian wrote:
: My guess on this one is that Solaris is slower for PostgreSQL because
: process switching is _much_ heavier on Solaris than other OS's.  This is
: because of the way they implemented processes in SVr4.  They got quite
: heavy, almost requiring kernel threads so you weren't switching
: processes all the time.
:
: In a sense threads were a solution to a process bloating problem.
: Linux/BSD have much lighter processes and hence work better for
: PostgreSQL.  Again, this is only a guess.
:
: MySQL does more stuff with threads while PostgreSQL switches process
: because each backend is a process.

Does more stuff with threads?  It does all stuff with threads.  Your
guess was our guess, which is why we tried shoving the thing over to a
Linux box.  Now if I only I could figure out why kernel CPU usage keeps
going up incrementally over time (went from roughly a 5% average to a
16% average in two days) the more we run the system.  All signs are
pointing to postgres.

VACUUM ANALYZE-ing the tables used to reduce it back down, but now, it
doesn't appear to be as effective (might go from 16% back down to
13%).  Anyone know what causes that, and better yet, anyone know how to
fix it?  We see similar behavior under Solaris.

* Philip Molter
* DataFoundry.net
* http://www.datafoundry.net/
* philip@datafoundry.net

pgsql-general by date:

Previous
From: GH
Date:
Subject: Re: Problem with null timestamp fields
Next
From: Jason Earl
Date:
Subject: Re: Problem with null timestamp fields