Re: Avoiding any locks in SQL Servers - read and understand....its magic.

"Guido Stepken" <stepken_at_little-idiot.de> schrieb im Newsbeitrag news:bhserr$26q$00$1_at_news.t-online.com...
> Hi, Billy !
>
> I don't really know, if PostgreSQL, Firebird, Informix, LogicSQL are
> phantasy products. The all support MVTO, MVCC. MS and other database
> makers haven't understood the great advantage of this technology. True,
> not implementing MBCC makes things much more simple for database
> programmers, but makes database programming much more expensive. Somehow
> this is wanted by MVP's, MSCD's, they earn more money.
>
> Locking is not neccessary, database performance increases very much,
> because clients (and server) do not have to wait for any lock to be
> released.

But postgres locks too, or at least it blocks the client from updating a row if
another started his updatetransaction first. So, where's the difference?

Here's the relevant part of the postgres doc: UPDATE, DELETE, and SELECT FOR UPDATE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as
of the query start time. However, such a target row may have already been updated (or
deleted or marked for update) by another concurrent transaction by the time it is found.
In this case, the would-be updater will wait for the first updating transaction to commit or
roll back (if it is still in progress).

Lots of Greetings!
Volker Received on Tue Aug 19 2003 - 06:02:13 CDT