Subject: Re: PostgreSQL
To: joerg@britannica.bec.de, Neil Conway <neilc@samurai.com>
From: Greg 'groggy' Lehey <grog@NetBSD.org>
List: tech-perform
Date: 02/02/2006 12:29:23
--tuifNR376H9qoyoc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thursday,  2 February 2006 at  2:54:18 +0100, joerg@britannica.bec.de wrote:
> On Thu, Feb 02, 2006 at 01:19:06AM +0000, segv@netctl.net wrote:
>> Threads can be created MUCH faster, they take up a lot less memory and they run
>> in the same address space, which means access to shared data is easy and fast.
>
> Come on. How often to do create a thread? Once per connection. How often
> do you create connections? Don't tell me for each HTTP request, that
> would be a nice major bottle neck to kill *independent* of the DB(MS) or
> OS.

Agreed, the time to create a thread is not the real issue (though it's
correct that they start faster).

On Wednesday,  1 February 2006 at 20:55:12 -0500, Neil Conway wrote:
> On Thu, 2006-02-02 at 01:19 +0000, segv@netctl.net wrote:
>> Threads can be created MUCH faster, they take up a lot less memory and they run
>> in the same address space, which means access to shared data is easy and fast.
>
> Threads start faster, but connection startup time should not be in the
> critical path for most well-designed applications: use connection
> pooling or persistent connections.

The real advantage of threads is that the scheduler overhead is less.

> Threads use less memory, but with COW the difference isn't *that*
> significant when dealing with hundreds of connections. By comparison,
> Apache boxes with a few hundred httpd processes are commonplace...

Apache now uses threads by preference.

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

--tuifNR376H9qoyoc
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFD4Wd7IubykFB6QiMRApS+AKCXrA27nlnHbslBPh0jep7m9Us7mQCgrolJ
tZfvG+V4Zwg8mJN2Af0EVHI=
=BPHL
-----END PGP SIGNATURE-----

--tuifNR376H9qoyoc--