BloGroonga

2018-03-29

Groonga 8.0.1リリース

今日は肉の日ですね!

Groonga 8.0.1をリリースしました!

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

  • [ログ] クエリーログ内でfilterの条件を表示するようにしました。
  • Windows版のGroongaにて、*.pdb*.dll*.exeと同じディレクトリにインストールされるようにしました。
  • [logical_count] filteredステージの動的カラムをサポートしました。
  • [logical_count] フィルタータイミングを新規追加しました。
  • [logical_select] フィルタータイミングを新規追加しました。
  • [logical_range_filter] 大きい結果セットに対するウィンドウ関数の動作を最適化しました。
  • [select] --match_escalationパラメーターを追加しました。
  • [httpd] バンドルしているnginxのバージョンを1.13.10に更新しました。
  • 共通接頭辞がどのトークンにもマッチしない時にメモリーリークする問題を修正しました。
  • 同一プロセスで複数のデータベースを開いている時に、異なるデータベースのキャッシュを使用してしまう問題を修正しました。
  • 比較時(>,>=,<,<=,==,!=)に、定数がオーバーフローまたはアンダーフローし得る問題を修正しました。

[ログ] クエリーログ内でfilterの条件を表示するようにしました。

この変更によって、どの条件でfilterされるかがわかるようになります。 具体的には、以下のように表示されます。

2018-02-15 19:04:02.303809|0x7ffd9eedf6f0|:000000013837058 filter(17): product equal "test_product"

上記は、product == "test_product"の条件で17件まで絞り込まれたことを表します。 この機能はデフォルトで無効になっており、以下の環境変数を設定することで有効になります。

GRN_QUERY_LOG_SHOW_CONDITION=yes

[logical_count] filteredステージの動的カラムをサポートしました。

いままで、logical_countでは、initialステージの動的カラムしかサポートしていませんでしたが、filteredステージの動的カラムも使えるようになります。

[logical_count][logical_select] フィルタータイミングを新規追加しました。

filteredステージで生成された動的カラムを使って、フィルター出来るようになります。 具体的には、以下のように使用します。

logical_select \
    --logical_table Entries \
    --shard_key created_at \
    --columns[n_likes_sum_per_tag].stage filtered \
    --columns[n_likes_sum_per_tag].type UInt32 \
    --columns[n_likes_sum_per_tag].value 'window_sum(n_likes)' \
    --columns[n_likes_sum_per_tag].window.group_keys 'tag' \
    --filter 'content @ "system" || content @ "use"' \
    --post_filter 'n_likes_sum_per_tag > 10' \
    --output_columns _key,n_likes,n_likes_sum_per_tag

  # [
  #   [
  #     0, 
  #     1519030779.410312,
  #     0.04758048057556152
  #   ], 
  #   [
  #     [
  #       [
  #         2
  #       ], 
  #       [
  #         [
  #           "_key", 
  #           "ShortText"
  #         ], 
  #         [
  #           "n_likes", 
  #           "UInt32"
  #         ], 
  #         [
  #           "n_likes_sum_per_tag", 
  #           "UInt32"
  #         ]
  #       ]
  #       [
  #         "Groonga", 
  #         10, 
  #         25
  #       ], 
  #       [
  #         "Mroonga", 
  #         15, 
  #         25
  #       ]
  #     ]
  #   ]
  # ]

--post_filter内で、filteredステージで作成した動的カラムn_likes_sum_per_tagを使用しているところがポイントです。 上記の例はlogical_selectですが、logical_countでも同様に使用できます。

[logical_range_filter] 大きい結果セットに対するウィンドウ関数の動作を最適化しました。

一致するレコードが十分見つかった場合は、残りのウィンドウに対してウィンドウ関数を適用しません。

現状では、この最適化は、最適化によるオーバーヘッドが無視出来ない場合、小さな結果セットに対しては、無効になります。

[select] --match_escalationパラメーターを追加しました。

--match_escalation yes とすることによって、マッチ演算のエスカレーションを強制的に有効にします。このパラメータは、 --match_escalation_threshold 99999....999 よりも強力です。--match_escalation yes は、 SOME_CONDITIONS && column @ 'query' もエスカレーションしますが、 --match_escalation_threshold ではしないためです。

デフォルトは、--match_escalation auto です。これは、既存の動作と同じです。

--match_escalation no とすることで、マッチ演算のエスカレーションを無効にできます。これは、 --match_escalation_threshold -1 と同様の動きになります。

共通接頭辞がどのトークンにもマッチしない時にメモリーリークする問題を修正しました。

以下の例のように、Groongaのあいまい検索において、共通の接頭辞がどのトークンにもマッチしない時にメモリーリークしていた問題を修正しました。

table_create Users TABLE_NO_KEY
[[0,0.0,0.0],true]
column_create Users name COLUMN_SCALAR ShortText
[[0,0.0,0.0],true]
table_create Names TABLE_PAT_KEY ShortText
[[0,0.0,0.0],true]
column_create Names user COLUMN_INDEX Users name
[[0,0.0,0.0],true]
load --table Users
[
{"name": "Tom"},
{"name": "Tomy"},
{"name": "Pom"},
{"name": "Tom"}
]
[[0,0.0,0.0],4]
select Users --filter 'fuzzy_search(name, "Atom", {"prefix_length": 1})'   --output_columns 'name, _score'   --match_escalation_threshold -1
[[0,0.0,0.0],[[[0],[["name","ShortText"],["_score","Int32"]]]]]

同一プロセスで複数のデータベースを開いている時に、異なるデータベースのキャッシュを使用してしまう問題を修正しました。

プロセス内でキャッシュを共有していたため、同一のプロセスで複数のデータベースを開いている場合、別のデータベースのキャッシュから結果を返してしまう事がある現象を修正しました。

比較時(>,>=,<,<=,==,!=)に、定数がオーバーフローまたはアンダーフローし得る問題を修正しました。

以下の例のように、比較対象のカラムの型を超える値を指定した場合に、オーバーフローまたは、アンダーフローを起こし、意図しない検索結果が返ってきてしまう現象を修正しました。

table_create Values TABLE_NO_KEY
[[0,0.0,0.0],true]
column_create Values number COLUMN_SCALAR Int16
[[0,0.0,0.0],true]
load --table Values
[
{"number": 3},
{"number": 4},
{"number": -1}
]
[[0,0.0,0.0],3]
select Values   --filter 'number > 32768'   --output_columns 'number'
[[0,1522305525.361629,0.0003235340118408203],[[[3],[["number","Int16"]],[3],[4],[-1]]]]

32768がInt16の範囲(-32,768 ~ 32,767)を超えているため、オーバーフローを起こし、number > 32768number > -32768と評価されていました。 今回の修正で、上記のようにオーバーフローまたは、アンダーフローが起きた場合には、何も結果を返さないように修正しています。

さいごに

8.0.0からの詳細な変更点は8.0.1リリース 2018-03-29を確認してください。

それでは、Groongaでガンガン検索してください!

2018-03-08

PostgreSQL用高速日本語全文検索モジュールPGroonga(ぴーじーるんが) 2.0.3リリース

PostgreSQLで高速日本語全文検索をできるようにするPGroongaの2.0.3をリリースしました!

新規ユーザーの方は、PGroonga 2.0.2のリリースアナウンスのPGroongaについても参照してください。

ハイライト

2.0.3でのハイライトは次の通りです。

  • サブSELECTのパフォーマンスが向上

  • text[]の更新パフォーマンスが向上

  • pgroonga_jsonb_full_text_search_ops_v2演算子クラスの追加(JSON内のテキストだけを検索する場合はjsonb型のデフォルトの演算子クラスよりも高速)

  • WAL関連の機能強化

  • オンラインバックアップの実現を支援する機能を追加

  • timestamp (without time zone)型のインデックスの修正
    • アップグレード後にインデックスの再作成が必要
  • pgroonga_text_array_full_text_search_ops_v2演算子クラスの修正
    • アップグレード後にインデックスの再作成が必要

アップグレード

以前のバージョンと互換性があるので互換性がある場合の手順でアップグレードできます。

ただし、以下のPGroongaのインデックスはアップグレード後に再作成する必要があるので注意してください。

  • timestamp (without time zone)型のカラムのインデックス

  • pgroonga_text_array_full_text_search_ops_v2演算子クラスを使っているインデックス

    • この演算子クラスはtext[]型のデフォルトの演算子クラスなので演算子クラスを指定していない場合は対象になります。

インデックスの再作成にはREINDEXが便利です。

REINDEX INDEX インデックス名;

機能強化

今回のリリースでの機能強化の詳細はリリースノート内のリンクを参照してください。

サポートサービス

PGroongaのサポートサービスを提供しています。インデックスや検索の設計方法に関するコンサルティングやトラブル時の調査、パフォーマンス改善・新機能追加などの技術支援など、PGroongaに関わるサポートが必要な場合はご相談ください。

まとめ

PGroongaの新しいリリースを紹介しました。運用面で便利な機能が増えています。

ここで紹介したもの以外の変更点はリリースノートを参照してください。

PostgreSQLで高速に日本語全文検索をしたいという方はPGroongaを使ってガンガン検索してください!

2018-02-09

Groonga 8.0.0リリース

今日は肉の日ですね!

Groonga 8.0.0をリリースしました!

メジャーバージョンアップです! メジャーバージョンアップですが、互換性は壊れていないので、安心してアップグレードしてください!

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

  • select --drilldown_adjuster--drilldowns[LABEL].adjusterをサポートしました。

  • between between()の引数に境界値を指定しなくても動作するようにしました。

  • ハッシュテーブルのメモリリークを修正しました。

select --drilldown_adjuster--drilldowns[LABEL].adjusterを追加しました

selectの引数に--drilldown_adjuster--drilldowns[LABEL].adjusterを追加しました。 drilldown結果に対して、--adjusterと同様スコアの調整ができます。

以下のように使用します。

table_create Categories TABLE_PAT_KEY ShortText

table_create Tags TABLE_PAT_KEY ShortText
column_create Tags categories COLUMN_VECTOR|WITH_WEIGHT Categories

table_create Memos TABLE_HASH_KEY ShortText
column_create Memos tags COLUMN_VECTOR Tags

column_create Categories tags_categories COLUMN_INDEX|WITH_WEIGHT \
  Tags categories

load --table Tags
[
{"_key": "groonga", "categories": {"full-text-search": 100}},
{"_key": "mroonga", "categories": {"mysql": 100, "full-text-search": 80}},
{"_key": "ruby", "categories": {"language": 100}}
]

load --table Memos
[
{
  "_key": "Groonga is fast",
  "tags": ["groonga"]
},
{
  "_key": "Mroonga is also fast",
  "tags": ["mroonga", "groonga"]
},
{
  "_key": "Ruby is an object oriented script language",
  "tags": ["ruby"]
}
]

select Memos \
  --limit 0 \
  --output_columns _id \
  --drilldown tags \
  --drilldown_adjuster 'categories @ "full-text-search" * 2 + categories @ "mysql"' \
  --drilldown_output_columns _key,_nsubrecs,_score
[
  [
    0,
    0.0,
    0.0
  ],
  [
    [
      [
        3
      ],
      [
        [
          "_id",
          "UInt32"
        ]
      ]
    ],
    [
      [
        3
      ],
      [
        [
          "_key",
          "ShortText"
        ],
        [
          "_nsubrecs",
          "Int32"
        ],
        [
          "_score",
          "Int32"
        ]
      ],
      [
        "groonga",
        2,
        203
      ],
      [
        "mroonga",
        1,
        265
      ],
      [
        "ruby",
        1,
        0
      ]
    ]
  ]
]

上記の例では、categoriesfull-text-searchmysqlを持つレコードのスコアを調整しています。

between between()の引数に境界値を指定しなくても動作するようにしました

between()は、最小値、最大値を含む/含まないを指定する引数を含めて5つの引数が必要でしたが、 今回のリリースから、最小値、最大値を含む/含まないを指定しなくても使えるようになりました。

以下のように3つの引数で使うことができます。 3つの引数で使用した場合は、最小値、最大値を含むものとして処理されます。

table_create Users TABLE_HASH_KEY ShortText
column_create Users age COLUMN_SCALAR Int32

table_create Ages TABLE_PAT_KEY Int32
column_create Ages users_age COLUMN_INDEX Users age

load --table Users
[
{"_key": "alice",  "age": 17},
{"_key": "bob",    "age": 18},
{"_key": "calros", "age": 19},
{"_key": "dave",   "age": 20},
{"_key": "eric",   "age": 21}
]

select Users --filter 'between(age, 18, 20)'
[
  [
    0,
    0.0,
    0.0
  ],
  [
    [
      [
        3
      ],
      [
        [
          "_id",
          "UInt32"
        ],
        [
          "_key",
          "ShortText"
        ],
        [
          "age",
          "Int32"
        ]
      ],
      [
        2,
        "bob",
        18
      ],
      [
        3,
        "calros",
        19
      ],
      [
        4,
        "dave",
        20
      ]
    ]
  ]
]

ハッシュテーブルのメモリリークを修正しました

この修正により、Windowsにおいて、クエリーを実行し続けるだけで、Groongaに接続できなくなることがある現象を解消しています。

さいごに

7.1.1からの詳細な変更点は8.0.0リリース 2018-02-09を確認してください。

それでは、Groongaでガンガン検索してください!

2018-01-29

Groonga 7.1.1リリース

今日は肉の日ですね!

Groonga 7.1.1をリリースしました!

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

  • Quorum matchをサポートしました。filterquery両方で使えます。

  • filter で類似度のしきい値を指定できるよう改良しました。

  • grndb recover--force-lock-clearオプションを追加しました。

  • サロゲートペアをload できるように改良しました。

  • expireの実施回数を減らす環境変数GRN_II_REDUCE_EXPIRE_ENABLEを追加しました。

  • logical_range_filterpost_flterオプションを追加しました。

Quorum matchをサポートしました。filterquery両方で使えます

Quorum matchは、曖昧検索をする際に使用します。設定したしきい値を超える数のトークンが存在するレコードにマッチします。 例えば、"I have a pen"が"I"、"have"、"a"、"pen"の4つのトークンに分割されるとすると、これらのトークンのうちいずれか3つ以上のトークンを持つレコードが マッチします。

以下のように使用します。

--filter column *Q${THRESHOLD} "I have a pen"

--query *Q${THRESHOLD}"I have a pen"

filter で類似度のしきい値を指定できるよう改良しました

以下のように類似度のしきい値をカスタマイズして、類似文章検索が出来るようになります。 類似文章検索は、以下の例で言うと、"document"と似たようなレコードを検索する機能です。

--filter column *S${SIMILARITY_THRESHOLD} "document"

grndb recover--force-lock-clearオプションを追加しました

通常テーブルにロックが残留していた場合は安全に復旧できないため、自動復旧できませんが、このオプションを使用することでテーブルにロックが残留していても、grndb recoverを実行することができます。 強制的に復旧するので、安全に復旧することはできません。 おいおい問題が発生したとしても、すぐにデータベースを操作したい場合に使うことを想定しています。

以下のように使用します。

 % grndb recover --force-lock-clear DB_PATH

サロゲートペアをloadできるように改良しました

loadコマンドで入力するJSON内にサロゲートペアの文字を使用できます。 以下のように4byteのUnicode文字列を "\uD83C\uDF7A" の形式で扱えるようになります。

たとえば 🍺 (0xF0 0x9F 0x8D 0xBA) を \uD83C\uDF7A と記述できます。

expireの実施回数を減らす環境変数GRN_II_REDUCE_EXPIRE_ENABLEを追加しました

GRN_II_REDUCE_EXPIRE_ENABLE=no は無効になり、GRN_II_REDUCE_EXPIRE_ENABLE はデフォルトで有効になります。

logical_range_filterpost_flterオプションを追加しました。

filtered ステージで生成されるカラムに対して、さらにfilterを実行できます。

さいごに

7.1.0からの詳細な変更点は7.1.1リリース 2018-01-29を確認してください。

それでは、Groongaでガンガン検索してください!

2017-12-29

Groonga 7.1.0リリース

今日は肉の日ですね!

Groonga 7.1.0をリリースしました!

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

  • load のクエリーログのフォーマットを改良しました。

  • logical_count のクエリーログのフォーマットを改良しました。

  • logical_select のクエリーログのフォーマットを改良しました。

  • delete のクエリーログのフォーマットを改良しました。

  • ドリルダウンでベクター型のカラムをサポートしました。

  • grn_bulk_*() APIにおいて、 realloc() が呼ばれる回数を削減しました。

  • 関数 index_column_source_records を新規に追加しました。インデックスカラムのソースを取得することができます。

load のクエリーログのフォーマットを改良しました。

loadのクエリーログに以下の情報が表示されるようになります。

  • ロードしたレコード数
  • ロードがエラーになったレコードとカラムの数
  • 総レコード数

具体的には、以下のように表示されます。

2017-12-29 15:23:47.049299|0x7ffe8af29a50|:000000001209848 load(3): [1][2][3]
2017-12-29 15:23:47.049311|0x7ffe8af29a50|<000000001221494 rc=-22

load直後の()の中の数字は、ロードしたレコード数、1番目の[]の中の数字は、ロードに失敗したレコード数、2番目の[]の中の数字はロードに失敗したカラム数、3番目の[]の中の数字は、総レコード数を表します。

logical_count のクエリーログのフォーマットを改良しました

logical_countのクエリーログに以下の情報が表示されるようになります。

  • 検索にマッチしたレコード数

具体的には、以下のように表示されます。

2017-12-29 15:25:06.068077|0x7fffedde8460|:000000001276405 count(2)
2017-12-29 15:25:06.068107|0x7fffedde8460|<000000001305264 rc=0

count直後の()の中の数字が、検索にマッチしたレコード数を表します。

logical_select のクエリーログのフォーマットを改良しました

logical_select のクエリーログに以下の情報が表示されるようになります。

  • 検索にマッチしたレコード数
  • ドリルダウンした数
  • ラベルつきのドリルダウンをした数

具体的には、以下のように表示されます。

2017-12-29 15:19:53.703472|0x7ffe0ce4e650|:000000001372833 filter(1)
2017-12-29 15:19:53.703499|0x7ffe0ce4e650|:000000001397623 select(1)[Logs_20170315]
2017-12-29 15:19:53.703796|0x7ffe0ce4e650|:000000001695440 filter(2)
2017-12-29 15:19:53.703813|0x7ffe0ce4e650|:000000001711123 select(2)[Logs_20170316]
2017-12-29 15:19:53.704024|0x7ffe0ce4e650|:000000001923225 filter(2)
2017-12-29 15:19:53.704040|0x7ffe0ce4e650|:000000001937931 select(2)[Logs_20170317]
2017-12-29 15:19:53.704198|0x7ffe0ce4e650|:000000002096788 output(5)
2017-12-29 15:19:53.704354|0x7ffe0ce4e650|<000000002253133 rc=0

select直後の()の中の数字は、実行されるクエリーによって、検索にマッチしたレコード数、ドリルダウン結果のレコード数、ラベル付きドリルダウンした結果のレコード数を表します。 また、シャード毎に結果を表示するようになっています。 上記例では、3つのシャードが存在するので、selectが3つ出力されています。 末尾の[]は、検索したテーブル名が表示されます。

delete のクエリーログのフォーマットを改良しました

delete のクエリーログに以下の情報が表示されるようになります。

  • 削除したレコード数と削除に失敗したレコード数
  • 削除後に残ったレコード数

具体的には、以下のように表示されます。

2017-12-29 15:27:30.002184|0x7fff769b2340|:000000032051813 delete(2): [0][1]
2017-12-29 15:27:30.002196|0x7fff769b2340|<000000032062599 rc=0

delete直後の()の中の数字は、削除した件数、1番目の[]の中の数字は、削除に失敗した件数、2番目の[]の中の数字は、deleteコマンドを実行した結果、残ったレコード数を表します。

ドリルダウンでベクター型のカラムをサポートしました

ベクター型のカラムに対して、ドリルダウンできるようになります。

以下のように drilldown_calc_target にベクターカラムを指定して、ベクターカラムの要素の中で 最小の値や最大の値、合計値、平均値等を出力できるようになっています。

table_create Tags TABLE_PAT_KEY ShortText

table_create Memos TABLE_HASH_KEY ShortText
column_create Memos tag COLUMN_SCALAR Tags
column_create Memos scores COLUMN_VECTOR Int64

load --table Memos
[
{"_key": "Groonga1", "tag": "Groonga", "scores": [10, 29]},
{"_key": "Groonga2", "tag": "Groonga", "scores": [20]},
{"_key": "Groonga3", "tag": "Groonga", "scores": [60, 71]},
{"_key": "Mroonga1", "tag": "Mroonga", "scores": [61, 62, 63]},
{"_key": "Mroonga2", "tag": "Mroonga", "scores": [24, 20, 16]},
{"_key": "Mroonga3", "tag": "Mroonga", "scores": [8, 5, 2]},
{"_key": "Rroonga1", "tag": "Rroonga", "scores": [3]},
{"_key": "Rroonga2", "tag": "Rroonga", "scores": [-9, 0, 9]},
{"_key": "Rroonga3", "tag": "Rroonga", "scores": [0]}
]

上記のようなテーブルに対して、以下のクエリーを発行すると、tagGroongaを持つレコード、tagMroongaを持つレコード、tagRroongaを持つレコードのscoresカラムの中から最小値、最大値、scoresカラムの各要素を合計した値、scoresカラムの要素の平均値を計算し出力します。

select Memos \
  --limit 0 \
  --drilldowns[tag].keys tag \
  --drilldowns[tag].calc_types 'MAX, MIN, SUM, AVG' \
  --drilldowns[tag].calc_target scores \
  --drilldowns[tag].output_columns _key,_max,_min,_sum,_avg

したがって、上記のクエリーの結果はそれぞれ以下のようになります。(説明に不要な部分は一部割愛して記載しています。) 左から_key, _max_min_sum_avgの値となります。

["Groonga", 71, 10, 190, 38.0],
["Mroonga", 63, 2, 261, 29.0],
["Rroonga", 9, -1, 3, 0.6],

grn_bulk_*() APIにおいて、 realloc() が呼ばれる回数を削減しました。

クエリーの実行結果表示の際に、応答サイズが大きいとWindows版のみ表示速度が遅くなる現象を改善しました。 この変更によって、Windows版においてクエリーの実行結果表示のパフォーマンスが向上します。 例えば、出力が100MBを超える場合には、約100倍速くなります。

関数 index_column_source_records を新規に追加しました

この関数を使って、以下のようにインデックスカラムのソースを取得することができます。

plugin_register functions/index_column

table_create Memos TABLE_HASH_KEY ShortText

table_create Terms TABLE_PAT_KEY ShortText \
  --default_tokenizer TokenBigram \
  --normalizer NormalizerAuto
column_create Terms index COLUMN_INDEX|WITH_POSITION Memos _key

load --table Memos
[
{"_key": "Groonga is a fast full text search engine."},
{"_key": "Mroonga is a MySQL storage engine based on Groonga."},
{"_key": "Rroonga is a Ruby bindings for Groonga."}
]

上記のようなテーブルに対して、以下のクエリーを発行すると、Termsテーブルに登録されているトークンが出現するレコードを表示できます。

select Terms \
  --limit -1 \
  --sort_keys _id \
  --columns[index_records].stage output \
  --columns[index_records].type Memos \
  --columns[index_records].flags COLUMN_VECTOR \
  --columns[index_records].value 'index_column_source_records("index")' \
  --output_columns '_id, _key, index_records'

上記のクエリーの結果はそれぞれ以下のようになります。(説明に不要な部分は一部割愛して記載しています。) 一番右の値が、index_column_source_recordsの結果となります。

[ 1, "groonga", [ "Groonga is a fast full text search engine.", "Mroonga is a MySQL storage engine based on Groonga.", "Rroonga is a Ruby bindings for Groonga." ] ],
[ 2, "is", [ "Groonga is a fast full text search engine.", "Mroonga is a MySQL storage engine based on Groonga.", "Rroonga is a Ruby bindings for Groonga." ] ],
(省略)

さいごに

7.0.9からの詳細な変更点は7.1.0リリース 2017-12-29を確認してください。

それでは、Groongaでガンガン検索してください!

2017-11-29

Groonga 7.0.9リリース

今日は肉の日ですね!

Groonga 7.0.9をリリースしました!

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

in_valuesで126を超える引数を指定できるようにしました

これまでのバージョンでは、 in_values の引数は126個までという制限がありました。 そのため、多数の OR== を使っているクエリを in_values を使ってまとめようとしても、引数の個数の制限のためできない置き換えられない場合がありました。

今回のリリースでは、その制限を撤廃したので、上限を気にすることなく in_values を使えるようになりました。

logical_range_filterlogical_countにて動的カラムをサポートしました

selectlogical_select だけでなく、logical_range_filter でも動的カラムが使えるようになりました。

logical_range_filter は十分なレコードがマッチしたら検索をやめるため、マッチさせたい数が決まっている状況では、すべてのマッチするレコードを検索する logical_select よりも性能面でメリットがあります。

さいごに

7.0.8からの詳細な変更点は7.0.9リリース 2017-11-29を確認してください。

それでは、Groongaでガンガン検索してください!