From: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Anyone working on better transaction locking? |
Date: | 2003-04-13 06:29:59 |
Message-ID: | 200304131159.59075.shridhar_daithankar@nospam.persistent.co.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sunday 13 April 2003 09:47, you wrote:
> Even if you'd gain as much as a 10% speed improvement by using threads
> to handle concurrent sorts and such instead of processes (an
> improvement that is likely to be very difficult to achieve), I think
> you're still going to be better off using processes. To justify the
> dangers of using threads, you'd need to see something like a factor of
> two or more gain in overall performance, and I don't see how that's
> going to be possible even on systems with very heavyweight processes.
I couldn't agree more.
There is just a corner case to justify threads. Looking around, it would be a
fair assumption that on any platforms threads are at least as fast as
processes. So using threads it is guarenteed that "sub-work" will be lot more
faster.
Of course that does not justify threads even in 5% of cases. So again, no
reason to use threads for sort etc. However the subprocesses used should be
simple enough. A process as heavy as a full database connection might not be
too good.
Shridhar
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-04-13 06:43:16 | Re: Anyone working on better transaction locking? |
Previous Message | Joe Conway | 2003-04-13 06:11:53 | CVSup binary RPMs for Red Hat 9 available |