Kouhei Sutou
kou****@clear*****
2015年 8月 11日 (火) 20:42:29 JST
須藤です。 In <CAN-DUMTjMec-WM9Fmo4k7f=o45ud****@mail*****> "[groonga-dev,03397] PostgreSQLとgroongaのレコードの紐付けにctidを使うのは大丈夫なのでしょうか？" on Tue, 11 Aug 2015 11:41:54 +0900, Hiroaki Nakamura <hnaka****@gmail*****> wrote: > pgroongaのソースを見ると > https://github.com/pgroonga/pgroonga/blob/6d3600c12c5abda068facebacc44751eecd48eb9/pgroonga.c#L1027-L1036 > で static uint64 CtidToUInt64(ItemPointer ctid) という関数が定義されて > おり、 > PostgreSQLのデータ行のctidをuint64型に変換してgroongaのテーブルのctid > 列に格納しています。 > > 一方、 > https://www.postgresql.jp/document/9.4/html/ddl-system-columns.html > のctidの説明を見ると >> テーブル内における、行バージョンの物理的位置を表します。ctidは行バー > ジョンを >> 素早く見つけるために使うことができますが、行のctidは更新されたり、 > VACUUM FULL >> により移動させられたりすると変わります。したがって、ctidは長期の行識 > 別子とし >> ては使えません。論理行を識別するためには、OID、あるいはさらに良いの > はユーザ >> 定義の通番数を使うべきです。 > と書かれています。 > > この説明を読む限り、ctidをgroongaのテーブルに保存しておいてPostgreSQL > のレコードとの紐付けに > 使うのは良くないような気がします。 このドキュメントを読むとそう思いますよねぇ。 ですが、これで大丈夫なんです。 これはSQLで使う場合の話で、拡張機能としてインデックスを実装 する場合はそんなことはないんです。 というか、インデックスはctidを返すことを求められるので、ctid を保存しておかないと適切な結果を返すことはできません。 VACUUM FULLしたときも大丈夫なのかは試さないとわからないんで すが、GINもctidを格納しているように見えるので大丈夫じゃない かなぁと思っています。 念のため試してみるか！という気持ちになったら結果を教えてもら えるとうれしいです。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ: http://www.clear-code.com/services/code-reader/
