Re: Threaded PosgreSQL server
От | |
---|---|
Тема | Re: Threaded PosgreSQL server |
Дата | |
Msg-id | Pine.GSO.4.10.10202061228090.2099-100000@goldengate.kojoworldwide.com. обсуждение исходный текст |
Ответ на | Re: Threaded PosgreSQL server ("Marc G. Fournier" <scrappy@hub.org>) |
Ответы |
Re: Threaded PosgreSQL server
Re: Threaded PosgreSQL server |
Список | pgsql-hackers |
On Wed, 6 Feb 2002, Marc G. Fournier wrote: > Right now, from everythign I've heard, making the code thread-safe is one > big onerous task ... but if we were to start incorporating changes from > the 'thread work' that is being done now, into the base server, and ppl > start thinking thread-safe when they are coding new stuff, over time, this > task becomes smaller ... > I agree, once the move is made to thread-safe it becomes much easier to maintain thread-safe code. I also very much like the idea of multiple thread/process models that could be chosen from. I think the question has always been the inital cost vs. benefit. The group has not seen much to be gained for the amount of initial work involved. After working with the code, I too felt it wasn't worth it. After revisiting the threaded code after a long break I now see some real benefits to threading. For example, I was able to incorporate Tom Lane's lazy_vacuum code to do relation clean up automatically when a threshold of page writes occurred. I was also able to use the freespace information to be shared among threads in the process without touching shared mem. As a result, a pgbench run with 20 clients and over 1,000,000 trasactions maintained a more or less constant tps with manual vacuum commands and far less heap expansion. You can do this with processes (planned for 7.3 I think) but I think it was much easier with threads. Other things may open up with threads as well like Java stored procedures. Anyway, now I think it is worth it. Myron mkscott@sacadia.com
В списке pgsql-hackers по дате отправления: