29 January 2013

One Step Closer to Nirvana

For years, many years, there's been the quandary: if one is updating a row, and not updating key columns, should others be able to concurrently update other non-key columns, even the one I just updated? So far as I know, Postgres is the first database to tiptoe in that direction. This isn't cell locking, though.

With this level of locking, UPDATE queries that do not involve columns of the tuple key can perform concurrently.

The argument will be "but chaos will ensue!" I don't buy it. With conventional row level locking, my updates will get overwritten by your updates, just with lowered concurrency. And, by definition, non-key attributes are fully mutable and irrelevant to identity or process; that's why they're non-key. High normal form schemas fit right in with this locking regime: tables are narrower, with fewer non-key attributes per table. The flatfile folks oft times argue that same-named attributes have to have separate ranges, depending on table; foreign keys and normalization are evil. May they fry in hell.

No comments: