Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Threaded PosgreSQL server
Date
Msg-id 20020207204526.Q50941-100000@earth.hub.org
Whole thread Raw
In response to Re: Threaded PosgreSQL server  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
On Thu, 7 Feb 2002, mlw wrote:

> How does it depend? If you have one process with multiple threads, you
> will bump up against the process limit of file handles.

So?  Use an OS that doesn't impose such limits, or lets you increase them?

> Again, How does it depend? If you have one process, there is a limit to
> the amount of memory it can access. 3gig (2gig on older Windows) of
> process space it is a classic limitation to x86 operating systems.

But, we aren't talking about one *big* process with many threads ... we
are talking several processes that make use of threads to speed up various
processes ... kinda like programming in C for 99% of a project, but going
to assembly for stuff that could use that little bit of a boost ...

> I guess all I am saying, is that a person's time is really the only
> limited resource. Tom, Bruce, Marc, Peter and everyone else have a
> limited amount of time. If I could influence how those guys spend their
> time, I would hope they spent time working on improving the
> functionality of PostgreSQL, not the tedium of making it thread safe.

Except that, as several ppl have pointed out, that 'tedium' could result
in functionality that we really don't have right now ... right now, with a
"non-threaded, single process per connection", you really aren't making
*as efficient of use* of a multi-CPU environment ... how many queries
spend a good deal of time sitting in an I/O wait state because it has to
wait untli all the data is read from the drive before it can start
processing?  Going to a large database/application, on a Quad+ server,
where you don't have *alot* of queries happening, but those that do are
*very* large ... that large query is currently stuck on the one CPU while
the other 3+ CPUs are sitting idle ... etc, etc ... there is functionality
that 'working around' in a non-threaded environment would be more tedious
then doing the code clean up itself, and, most likely, not near as
efficient as it could be ...

The first step has to be taken *sometime*, and best to encourage it while
we have ppl around that have the *knowledge* to take it ... god, I can
remember when doing the code cleanups to get configure integrated into our
build process (there was a time where configure didn't exist) was a
tedious process, but how many ppl out there could imagine us without it?



pgsql-hackers by date:

Previous
From: "D. Hageman"
Date:
Subject: Re: Threaded PosgreSQL server
Next
From: David Gould
Date:
Subject: 7.2 - changed array_out() - quotes vs no quotes