やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

📌 ？
トップ > SQLite3 > SQLite3コア関数　likelihood,likely,unlikely

SQLite3コア関数　likelihood,likely,unlikely

SQLite3

　クエリプラン最適化用。

成果物

likelihood,likely,unlikely関数とは何か

情報源

翻訳

likelihood

尤度（X、Y）関数は引数Xを変更せずに返します。Likelihood（X、Y）の値Yは、0.0から1.0までの浮動小数点定数でなければなりません。Likelihood（X）関数は、実行中（つまり、sqlite3_step（）の呼び出し中）に CPUサイクルを消費しないように、コードジェネレーターが最適化して除去するノーオペレーションです。Likelihood（X、Y）関数の目的は、引数Xが約Yの確率で真であるブール値であるというヒントをクエリプランナーに提供することです。likelyly（X）関数は、尤度（ X、0.0625）。可能性（X）関数は、尤度（X、0.9375）のための短い手です。

  • 尤度=likelihood
  • likelyly=unlikely

　以下2関数は短縮表現。

  • likely(X)=likelihood(X,0.9375)
  • unlikely(X)=likelihood(X,0.0625)

　尤度（ゆうど）とは、統計学において、ある前提条件に従って結果が出現する場合に、逆に観察結果からみて前提条件が「何々であった」と推測する尤もらしさ（もっともらしさ）を表す数値。

likely

likely（X）関数は、引数Xを変更せずに返します。可能性の高い（X）関数は、実行時（つまり、sqlite3_step（）の呼び出し中）に CPUサイクルを消費しないように、コードジェネレーターが最適化により除去するノーオペレーションです。Likes（X）関数の目的は、引数Xが通常は真であるブール値であるというヒントをクエリプランナに提供することです。likely（X）関数は、尤度（X、0.9375）と同等です。また、likelyly（X）も参照してください。

unlikely

likely（X）関数は、引数Xを変更せずに返します。unlikely（X）関数は、実行時（つまり、sqlite3_step（）の呼び出し中）に CPUサイクルを消費しないように、コードジェネレーターが最適化して除去するノーオペレーションです。unlikely（X）関数の目的は、引数Xが通常は真ではないブール値であるというヒントをクエリプランナーに提供することです。likely（X）関数は、尤度（X、0.0625）と同等です。

解釈

　翻訳をみてもわからん。以下により、クエリプラン調整用の関数であることがわかった。

　以下のように使う。

SELECT
...
WHERE likelihood(cname LIKE '%bach%', 0.05)
...

　cname列のうち'%bach%'に一致する行数が0.05(5%)であると想定したときの、最適なアルゴリズムを選択する。

　likelihoodがないときは1.0(100%)と想定してアルゴリズムを選択する。つまり、全行が'%bach%'のパターンに一致する想定でアルゴリズムを選択する。

いつ、どう使う？

　応答速度が遅いとき。特に、レコード数が膨大で、インデックスを貼って、vacuum,reindex済みなのに遅いとき。

　ただ、尤度の数値を算出する根拠がない。正確に出すためには特定キーワードとテーブル状態から算出せねばならない。その表から尤度を取得するという工程を経れば、そのぶん応答速度が低下するため本末転倒な気がする。

　つまり、適当なリテラル値を指定してやるのがマシな方法なのだろう。ふつうに考えると、絞り込み条件であるなら1より0に近くなるはず。ならばlikelyよりunlikelyのほうが使うだろう。5件中1件に絞りこめる見込みなら0.20(20%)となるだろう。

　尤度はキーワードやレコード状態によって変わる。よって、本関数はあくまで確率論的な解法でしかない。これで差が出るほど膨大なDBになり、性能限界を迎えたときに奥の手として検討すればよいだろう。

対象環境

$ uname -a
Linux raspberrypi 4.19.42-v7+ #1218 SMP Tue May 14 00:48:17 BST 2019 armv7l GNU/Linux

前回まで