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  ("Marc G. Fournier" <scrappy@hub.org>)
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:

Previous
From: Bruce Momjian
Date:
Subject: Re: /contrib/retep to gborg
Next
From: Anuradha Ratnaweera
Date:
Subject: Re: Postgresql and multithreading