Re: Anyone working on better transaction locking?

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

In response to

Browse pgsql-hackers by date

  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