SQLServerでは、構文 "（nolock）"を使用して、クエリがテーブルをロックしたり、同じテーブルをロックしている他のクエリによってブロックされたりしないようにすることができます。例えば
SELECT * FROM mytable (nolock) WHERE id = blah
Postgresの同等の構文は何ですか？PGでのテーブルロックに関するドキュメント（http://www.postgresql.org/docs/8.1/interactive/sql-lock.html ）を見つけましたが、すべてがテーブルをロックする方法を対象としているようで、ロックされていないことを確認していません。 。
ロックが必要でない限り、SELECTはPostgreSQLのテーブルをロックしません。
SELECT * FROM tablename FOR UPDATE;
PostgreSQLはMVCCを使用してロックの競合を最小限に抑え、マルチユーザー環境で妥当なパフォーマンスを実現します。リーダーは、ライターや他のリーダーと競合しません。
調査を行ったところ、SQLServerのNOLOCKヒントはREADUNCOMMITTEDトランザクション分離レベルとほぼ同じであるようです。PostgreSQLでは、を設定できREAD UNCOMMITTEDますが、レベルをサイレントにアップグレードしますREAD COMMITTED。 READ UNCOMMITTEDサポートされていません。
トランザクション分離に関するPostgreSQL8.4のドキュメント：http ：//www.postgresql.org/docs/8.4/static/transaction-iso.html
これは古い質問ですが、実際の質問は答えられていないと思います。
SELECTクエリ（句を含まないfor update）は、行（またはテーブル）をロックしたり、テーブルへの同時アクセスをブロックしたりすることはありません。並行DML（INSERT、UPDATE、DELETE）もSELECTステートメントをブロックしません。
(nolock)簡単に言えば、Postgresでは必要ありません。リーダーがライターをブロックすることはなく、ライターがリーダーをブロックすることはありません
nolockまたはreadpastの目的は、レコードが現在ロックされているかどうかを確認することです。ユーザーはこれを更新で使用して、識別されたレコードが変更されたかどうか（行の影響を受けるかどうか）を確認できます。レコードがロックされていない場合、影響を受ける行は1になります。oの場合、レコードはロックされています
その結果に基づいて、ユーザーはselect for updateを使用して、自分で使用できるようにロックすることができます。
すべてのSQLステートメントは暗黙のトランザクションです。NOLOCKヒントは、（READ UNCOMMITTED）DIRTY READトランザクション分離レベルに対応します。
BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT COUNT(1) FROM my_table;
END;
実際、このコードは同じことを行いますBEGIN TRANSACTION ISOLATION LEVEL READ COMMITTEDが、期待される動作をさらに保証します。
また、本当に必要な場合を除いて、COUNT（*）の使用は避けてください。