Hiroaki Nakamura
hnaka****@gmail*****
2015年 8月 11日 (火) 11:41:54 JST
中村です。 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のレコードとの紐付けに 使うのは良くないような気がします。 他の候補としてoidはどうかと思ったのですが、 https://www.postgresql.jp/document/9.4/html/datatype-oid.html を見ると > テーブル作成時にWITH OIDSが指定されているか、default_with_oids設定変数が有効な場合を除き、ユーザ作成のテーブルにはOIDは追加されません。 とか > ユーザ作成テーブルのOID列をプライマリキーとして使用するのはお勧めできません。 とか書いてあるので、これもよろしくないようです。 となると、ユーザ定義のテーブルに必ずプライマリーキーをつけてもらうことを前提として プライマリキーの値をgroongaのテーブルに格納して紐付けるようにするしか無いのかなと 思うのですが、いかがかでしょうか？ -- 中村 弘輝 )Hiroaki Nakamura) -------------- next part -------------- HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...Download
