Re: Antw: Re: Postgresql and multithreading - Mailing list pgsql-hackers
From | Shridhar Daithankar |
---|---|
Subject | Re: Antw: Re: Postgresql and multithreading |
Date | |
Msg-id | 3DB14FCF.7445.A2FEC2C@localhost Whole thread Raw |
In response to | Antw: Re: Postgresql and multithreading ("Ulrich Neumann" <U_Neumann@gne.de>) |
Responses |
Re: Antw: Re: Postgresql and multithreading
|
List | pgsql-hackers |
On 18 Oct 2002 at 18:10, Ulrich Neumann wrote: > Marc, > > not only the global variables are a problem. PostgreSQL doesn't clean > up > all the memory before a process terminates and you must deal with > signals between threads. OK, first of all let me say this. I am interested in seeing postgresql mutlithreaded but I don't think it's a good idea to provide a thread per connection. On slick unices like freebsd/linux, threads and processes are almost equally heavy. Besides if connection opening time for a database is an issue, application should cache the pool of connections. Databases are not web servers which should cater to thousands of connections per minute. I am interested in seeing postgresql multithreaded so that it performs better on SMP machine. Right now I am building/designing a *huge* database which is going to use at least 4 way machines. With number of connections very small, around 10-15 and being persistent, I am afraid that postgresql would not use all the available horsepower. > I've modified PostgreSQL that it is completely thread based and nearly > clean > with allocating/deallocating memory and I'm using signals between > threads. I am sure it must have been massive task. > I'm still VERY interested in giving those changes back to the > community, > but i think that my changes are still not wanted. Well, I understand your feeling but I am sure it's not the cases. People here have stated that there are other optimisation areas which needs to be addresses first. Threading is not ruled out but it's not on current radar either. I would be more than happy to assist you to make this happen. I have some experience in threads(pthreads on linux) but absolute no experience in postgresql code. Can we make a patch that converts a single module/operation to multithreaded? Let's say sequential table scan. I propose that such a conversion should be done under conditional compilation with default threaded behaviour as off. This would not disturb existing setup and behaviour where threads are not good enough. Besides since we are distributing almost exclusive work to threads, there should be little syncronisation issues. I request postgresql hackers to look up to this proposal favourably. This would be a good and gradual way to get threading in postgresql. Awaiting your feedback.. ByeShridhar -- The Consultant's Curse: When the customer has beaten upon you long enough, give him what he asks for, instead of what he needs. This is very strong medicine, and is normally only required once.
pgsql-hackers by date: