Database: Are there any vendors support column level locking? -

i'm studying database mechanism , see there 2 mechanisms: table level locking , row level locking. don't see column level locking , when google, see no document tell except link: database locking. in link:

a column level lock means columns within given row in given table locked. form of locking not commonly used because requires lot of resources enable , release locks @ level. also, there little support column level locking in database vendors.

so, vendors support column level locking ? , can tell me more detail, why column level locking requires lot of resources row level locking.

thanks :)

a lock cannot, in , of itself, require anything. it's abstract verb acting on abstract noun. why should locking column cost more locking byte, or file, or door? wouldn't put lot of stock in link.

the answer question lies in why locks exist -- protect -- , how dbmss engineered.

one of primary jobs of dbms manage concurrency: give each user, insofar possible, illusion data belong each one, time. different parties changing database, , dbms ensures changes appear users transaction, meaning no 1 sees "partial changes", , no one's changes ever "step on" another's. , can both change same thing, not @ same time: dbms makes sure 1 of goes first, , can later show was. dbms uses locks protect data while they're being changed, or prevent them being changed while they're being viewed.

note when "want change same thing", thing row (or rows). rows represent things out there in real world, things we're counting , tracking. columns attributes of things.

most dbmss organized internally around rows of data. data in memory pages , disk blocks, row-by-row. locks in these systems protect row-oriented data structures in memory. lock individual rows expensive; there lot of rows. expedient, many systems lock sets of rows (pages) or whole tables. fancier ones have elaborate "lock escalation" keep lock population under control.

there dbmss organized around columns. that's design choice; makes inserts more expensive, because row appears in several physical places (1/column), not neatly nestled between other rows. tradeoff summarization of individual columns cheaper in terms of i/o. be, in such systems, there "column locks", , there's no reason think they'd particularly expensive. observe, however, for insertion they'd affect concurrency in same way table lock: can't insert row table column locked. (there ways deal too. dbmss complex, reason.)

so answer question dbmss don't have "columns" internal structures lock protect. of do, column-lock specialty item, permits degree of column-wise concurrency, @ expense of otherwise being table-lock.