Re: Threaded PosgreSQL server
От | Marc G. Fournier |
---|---|
Тема | Re: Threaded PosgreSQL server |
Дата | |
Msg-id | 20020207204526.Q50941-100000@earth.hub.org обсуждение исходный текст |
Ответ на | Re: Threaded PosgreSQL server (mlw <markw@mohawksoft.com>) |
Список | 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 по дате отправления: