Re: Threaded PosgreSQL server
От | D. Hageman |
---|---|
Тема | Re: Threaded PosgreSQL server |
Дата | |
Msg-id | Pine.LNX.4.44.0202071552060.2624-100000@typhon.eecs.ku.edu обсуждение исходный текст |
Ответ на | Re: Threaded PosgreSQL server (mlw <markw@mohawksoft.com>) |
Ответы |
Re: Threaded PosgreSQL server
|
Список | pgsql-hackers |
On Thu, 7 Feb 2002, mlw wrote: <SNIP a bunch crap that will hopefully be implicitly explained and understand by the comments below> > There are, AFAIK two reasons to thread PostgreSQL: > > (1) Run the multiple connections in their own thread with the assumption > that this is more efficient for [n] reasons. > (2) Run a single query across multiple threads, thus parallelizing the > query engine. (3) Parallelize house keeping (for example vacuums) of the database. I think they are going to call this processes or something slated for the next version? (4) Replication (5) Referential Integritity cleanups (6) EXOTIC FEATURES: crossdb Oh yeah ... and we might be able to drop the whole startup time section from the TODO list. It all depends on how one wants to implement the threads into postgresql. Then again ... maybe a task of this endeavor would be more appropriately forked off and proceeded on as a seperate project (as it kinda as already been done). > 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. The people that do the biggest amount of coding should definately code what they feel is the best to work on - NO one is arguing that. If a few of them want to assist in this endeavor then they should do that as well. Most importantly - we shouldn't belittle the efforts of those that do see the vision of how this could be beneficial in the long run. My point is that I see more people wasting time complaining then it would take to make up a list of coding practices to follow for future work that will make the postgresql code base better. (Come on ... the first thing a programmer is taught is that global variables are BAD). -- //========================================================\\ || D. Hageman <dhageman@dracken.com> || \\========================================================//
В списке pgsql-hackers по дате отправления: