Archives of the TeradataForum

Message Posted: Fri, 05 May 2006 @ 09:39:08 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

I would pose the opposite question:

Why not always use ROW when requesting a downgrade to ACCESS locks?

Even if you request ROW (hash) locking, Teradata will use TABLE locks if the request involves multiple row hashes / multiple AMPs.

TABLE locks require an all-AMP step to acquire the lock, even if the DML execution itself would access only a single hash on a single AMP. And then the commit / end transaction will have to involve all AMPs to release the lock.

A TABLE lock modifier requires explicitly naming the table; ROW implicitly applies to all tables in the query, so it's simpler to code. (Though if you actually wanted ACCESS for only some tables and READ for others, I suppose that could be a reason to specify TABLE locks.)

One caveat: On releases prior to V2R5.0, if you requested ROW ACCESS locking but Teradata decided a TABLE lock was needed, it would default to TABLE READ instead of TABLE ACCESS.

	<Prev	Next>		<<First	<Prev	Next>	Last>>