Re: Anyone working on better transaction locking?

On Saturday 12 April 2003 16:24, you wrote:
> A better answer is that a database engine that can handle lots of
> concurrent requests can also handle a smaller number, but not vice
> versa. So it's clearly an advantage to have a database engine that
> can handle lots of concurrent requests because such an engine can be
> applied to a larger number of problems. That is, of course, assuming
> that all other things are equal...
>
> There are situations in which a database would have to handle a lot of
> concurrent requests. Handling ATM transactions over a large area is
> one such situation. A database with current weather information might
> be another, if it is actively queried by clients all over the country.
> Acting as a mail store for a large organization is another. And, of
> course, acting as a filesystem is definitely another. :-)

Well, there is another aspect one should consider. Tuning a database engine
for a specifiic workload is a hell of a job and shifting it to altogether
other end of paradigm must be justified.

OK. Postgresql is not optimised to handle lots of concurrent connections, at
least not much to allow one apache request handler to use a connection. Then
middleware connection pooling like done in php might be a simpler solution to
go rather than redoing the postgresql stuff. Because it works.

> This is true, but whether you choose to limit the use of threads to a
> few specific situations or use them throughout the database, the
> dangers and difficulties faced by the developers when using threads
> will be the same.

I do not agree. Let's say I put threading functions in posgresql that do not
touch shared memory interface at all. They would be hell lot simpler to code
and mainten than converting postgresql to one thread per connection model.

> Of course, back here in the real world they *do* have to worry about
> this stuff, and that's why it's important to quantify the problem.
> It's not sufficient to say that "processes are slow and threads are
> fast". Processes on the target platform may well be slow relative to
> other systems (and relative to threads). But the question is: for the
> problem being solved, how much overhead does process handling
> represent relative to the total amount of overhead the solution itself
> incurs?

That is correct. However it would be a fair assumption on part of postgresql
developers that a process once setup does not have much of processing
overhead involved as such, given the state of modern server class OS and
hardware. So postgresql as it is, fits in that model. I mean it is fine that
postgresql has heavy connections. Simpler solution is to pool them.

That gets me wondering. Has anybody ever benchmarked how much a database
connection weighs in terms of memory/CPU/IO BW. for different databases on
different platforms? Is postgresql really that slow?

Shridhar