<cbbrowne@cbbrowne.com> wrote in message
news:20030407194827.D0A3A56B1B@cbbrowne.com...
> Ron Peacetree wrote:
> > ...and if so, what are the current efforts focusing on?
>
> What is it that you think of as being potentially "better" about
some
> would-be-alternative "transaction locking" scheme?
>
> PostgreSQL already supports MVCC, which is commonly considered to be
the
> "better" scheme that eliminates a lot of need to lock data.
Agreed. FTR, the reason MVCC is "better" is that readers and writers
to the same data don't block each other. In "traditional" locking
schemes, readers don't block each other, but readers and writers to
the same data do. Clearly, writers to the same data must always block
each other.
Unfortunately, the performance of PostgreSQL MVCC in comparison to say
Oracle (the performance leader amongst MVCC DB's, and pretty much for
all DB's for that matter) is not competitive. Therefore there is a
need to improve the implementation of MVCC that PostgreSQL uses. If
someone can post a detailed blow-by-blow comparison of how the two
operate so that the entire list can see it that would be a Good Thing.
If I can, I'll put together the info and post it myself.
> Furthermore, the phrase "transaction locking" doesn't seem to
describe
> what one would want to lock. I wouldn't want to lock a
"transaction;"
> I'd want to lock DATA.
>
*sigh*. The accepted terminology within this domain for what we are
talking about is "transaction locking". Therefore we should use it to
ease communications. Argue with Codd and Date if you think the term
is a misnomer. Secondly, you are thinking only in the space
dimension. Locks have to protect data within a minimum space vs time
"bubble". That bubble is defined by the beginning and end of a
transaction, hence we call the locking of resources we do during that
bubble as "transaction locking".
