2010年2月17日

[pgsql-jp: 40186] Re:REINDEX中のロックについて

松尾さま

早速のご返信ありがとうございました。

> http://d.hatena.ne.jp/matsuou1/20090325/1237987824
こちらのページ、実は調査中に参考にさせていただきました!

上記ページに書いてあるREINDEX手順は正しく動作するでしょうか?

> 1.CREATE INDEX CONCURRENTLYで新しくインデックスを作成する。
> 2.古いインデックスを削除
> 3.先程作成したインデックスを元の名前にリネーム
> 4.Analyzeを実施

1で同じカラムに対するインデックスを作成しており、
2でDROPされるまでは重複している状態だと思いますが、
パフォーマンスに影響はないでしょうか?
#先にDROPするパターンはテストしてみましたが、
#CREATE INDEXが終わるまではインデックスは有効利用されないため、
#パフォーマンス的には落ちるだろうという見解です。

実際に上記手順を試されていましたら、
ぜひその時の状況を教えて頂きたいです。

よろしくお願いいたします。

2010年2月17日15:45 松尾 裕一 <yuichi.matsuo@xxxxx>:
> 松尾です。
>
> マニュアルに、「処理中のインデックスに対する排他ロックを取得するので、
> そのインデックスを使用する読み込みはブロックされます。 」とあるので、
> REINDEX中のインデックスを使用するSELECT文はロック待ちになって、
> インデックスを使用しない場合は、SELECT可能となると思います。
>
> 昔、調べたので参考まで。
> http://d.hatena.ne.jp/matsuou1/20090325/1237987824
>
> (2010/02/17 15:29), Takahito Yagami wrote:
>> やがみともうします。
>> 初めて投稿させていただきました。
>>
>> 基本的な事なのかもしれませんが教えて下さい。
>>
>> ■環境
>> ・CentOS 5.3
>> ・PostgreSQL 8.37
>>
>> マニュアルを見ると、「REINDEXはインデックスの元となるテーブルの
>> 書き込みをロックしますが、読み込みはロックしません。」とあり
>> トランザクションがなければ、運用中にREINDEX実施できるのでは
>> ないかと思っていました。
>> http://www.postgresql.jp/document/pg837doc/html/sql-reindex.html
>>
>> ところが、REINDEX中に実際にSELECT文を流してみると、
>> REINDEXが終わるまでwaitになってしまいました。
>>
>> 簡略化したサンプルとして、table1 に column1, column2 があるとします。
>>
>> 下記で全文検索(Ludia)用のインデックスを作成してあり、
>> CREATE INDEX senna_table1_column1 ON table1 USING fulltextb (column1);
>>
>> 下記コマンドでREINDEXします、
>> REINDEX INDEX senna_table1_column1;
>>
>> このREINDEX中のロック状態は、
>> ・table1テーブルに ShareLock
>> ・senna_table1_column1インデックスに ShareUpdateExclusiveLock と AccessExclusiveLock
>>
>> の状態でした。この状態で該当インデックスを使用しない
>> 下記SELECT文はREINDEXが終わるまで返ってきませんでした。
>> select * from table1 limit 10;
>>
>> §
>>
>> また、上記はLudia側の問題の可能性もあると思い btree インデックスでも
>> 同じようなテストをしました。
>>
>> 同じテーブルのcolumn2にbtreeインデックスをはる
>> CREATE INDEX senna_table1_column2 ON table1 USING btree (column2);
>>
>> 下記コマンドでREINDEXします、
>> REINDEX INDEX senna_table1_column2;
>>
>> このREINDEX中のロック状態は、
>> ・table1テーブルに ShareLock
>> ・senna_table1_column1インデックスに AccessExclusiveLock
>> (ShareUpdateExclusiveLockはありませんでした)
>>
>> この場合も同じく、下記SELECT文はREINDEXが終わるまで返ってきませんでした。
>> select * from table1 limit 10;
>>
>> §
>>
>> AccessExclusiveLock がSELECT文をブロックしていそうなのはわかるのですが、
>> 実行計画上で ロック中のインデックスを参照しなければ SELECTは
>> できると思っていましたが、上記が正常動作でしょうか?
>>
>> また、その場合マニュアルの「REINDEXはインデックスの元となるテーブルの
>> 書き込みをロックしますが、読み込みはロックしません。」という表現の
>> 意味するところはどうなるでしょうか?
>>
>> 根本的に勘違いしている可能性もありますが、どなたかご教授ください。
>>
>>
>
>
> --
> ----------------------------------------------------------
> 株式会社 レコチョク
> 〒150-0002 東京都渋谷区渋谷2丁目16番1号 日石渋谷ビル6階
> TEL:03-6418-7595 FAX:03-6418-7519
>
> システム部 事業システムグループ
> 松尾 裕一
> E-Mail: yuichi.matsuo@xxxxx
> ----------------------------------------------------------
>
>

--
矢上貴人(ヤガミタカヒト) <yagami@xxxxx>


投稿者 xml-rpc : 2010年2月17日 16:27
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/93406
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。