On Aug9, 2011, at 19:01 , Alvaro Herrera wrote: > Note that this means that UPDATE would always have to check whether key > columns are being modified. (I loosely talk about "key columns" here > referring to columns involving unique indexes. On tables with no unique > indexes, I think this would have to mean all columns, but I haven't > thought much about this bit.) > > To implement this, we need to augment MultiXact to store the lock type > that each comprising Xid holds on the tuple. Two bits per Xid are > needed. My thinking is that we could simply extend the "members" to add > a byte for every four members. This should be relatively simple, though > this forecloses the option of using MultiXact for some other purpose > than locking tuples. This being purely theoretical, I don't have a > problem with that.
Hm, I'm still not a huge fan of having the only the choice between locking all columns, or all columns that are part of a unique index. For multiple reasons. First, I'd like to see us support FKs which reference non-unqiue columns. As long as we restrict such FK constraints to ON UPDATE/DELETE RESTRICT (or NO ACTION), there's no conceptual difficulty in doing that. Yeah, I know that there'll probably be a lot of push-back on the grounds of standards compliance, but I still believe it'd be a nice feature. Second, there are lots of reasons for adding UNIQUE constraints to columns beside being on the referencing side of a FK constraint. If we make the lock strength taken by UPDATE depend on whether or not the UPDATE modified a column included in a UNIQUE constraint, we force people to drop UNIQUE constraints to avoid deadlocks, and thus indirectly support sloppy schema design. Couldn't we simply give the user a way to specify, per column, whether or not that column is a "KEY" column? Creating a foreign key constraint could still implicitly mark all referenced columns as KEY columns, but columns would no longer be "KEY" columns simply because they're part of a UNIQUE constraint. Users would be free to add arbitrary columns to the set of "KEY" columns by doing ALTER TABLE ALTER COLUMN SET KEY. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
