On Wednesday 27 June 2001 18:58, Bruce Momjian wrote:
> > I had almost given up on using Postgres for this system because under
> > Solaris, it just couldn't cut it (MySQL could do the work with one CPU
> > while Postgres took up even more CPU and required *both* CPUs to be
> > enabled), but when we moved the system to a Linux box, things worked
> > much better.
> Ah, back to a PostgreSQL topic. :-)
> 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.
Now, the question of the week:
Is supporting a thread model for an inefficient OS a desirable thing to do,
when more efficient OS kernels are available such as FreeBSD 4.x and Linux
2.4? My opinion is that our existing model, when used with a
connection-pooling frontend, is rather efficient. (Yes, I use a
connection-pooling frontend. Performance is rather nice, and I don't have to
have a full backend spawned for every page hit.)
In fact, on a Linux box threads show as processes. While I know that the
kernel actually supports themin a slightly different manner than processes,
they have more similarities than differences.
However, even on OS's where threads are supported, the mechanism to support
those threads must be an efficient one -- not all pthreads libraries are
created equal. Many are frontends (expensive ones, at that) for plain old
processes.
Does anyone know of a resource that details the 'weight' of processes for our
supported platforms? [reply off-list -- I'll be glad to summarize responses
to HACKERS, ADMIN, or PORTS, as appropriate, if desired.]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
