アカウント名:
パスワード:
にもかかわらずGEQOを使うのは、大量のJOINを伴うようなプランの取りうる組み合わせが爆発した場合に時間がかか
殆どのケースで最適解への収束が行われるでしょう
そういうのは「保証」って言わないんですよ。
DBの問い合わせプランの最適化って、大抵は、最適解じゃなくて、近似解だと思うのですけど。
最適化には二種類あって、コンパイラとかタスクスケジューラの最適化って、基本的に最適解を求めないってのが大半で、それでも最適化っていってる気がします。そういう場合は、最適解への収束をそもそも考えてなくて、なにもしないより良くなるとか、相対的な性能改善を目標にしているのかと。
数学的な最適化っていうと、絶対的な最適解を見つけることが目標で、だからこそ、最適解へ収束って話になると、保証って話が出てきたのかと。
DBの問い合わせプランの最適化って、大抵は、最適解じゃなくて、
もちろん評価関数の問題で、それが現実には最適解じゃない可能性もありますが:D
はっきり言っておくと、DBの問い合わせプランは順列組み合わせ問題に近く、テーブルのJOINやインデックスの選択肢が少ない殆どのケースでプラン数が数個~数十個しかなく、通常全件調査してもコスト場問題ない、と書けば満足ですか?
あなたがPostgreSQLに詳しいのは分かりましたから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
収束性 (スコア:0)
本当に?最適解への収束性が理論的に保証できるようなやさしい問題なら、そもそもGAなんてくだらない方法は使わない方がいいのに。
保証で
Re:収束性 (スコア:3, 興味深い)
にもかかわらずGEQOを使うのは、大量のJOINを伴うようなプランの取りうる組み合わせが爆発した場合に時間がかか
Re:収束性 (スコア:0, フレームのもと)
Re:収束性 (スコア:1)
Re:収束性 (スコア:0)
DBの問い合わせプランの最適化って、大抵は、最適解じゃなくて、近似解だと思うのですけど。
最適化には二種類あって、コンパイラとかタスクスケジューラの最適化って、基本的に最適解を求めないってのが大半で、それでも最適化っていってる気がします。そういう場合は、最適解への収束をそもそも考えてなくて、なにもしないより良くなるとか、相対的な性能改善を目標にしているのかと。
数学的な最適化っていうと、絶対的な最適解を見つけることが目標で、だからこそ、最適解へ収束って話になると、保証って話が出てきたのかと。
横やりなのでACRe:収束性 (スコア:1)
もちろん評価関数の問題で、それが現実には最適解じゃない可能性もありますが:D
Re:収束性 (スコア:0)
あなたがPostgreSQLに詳しいのは分かりましたから。
Re:収束性 (スコア:1)
はっきり言っておくと、DBの問い合わせプランは順列組み合わせ問題に近く、テーブルのJOINやインデックスの選択肢が少ない殆どのケースでプラン数が数個~数十個しかなく、通常全件調査してもコスト場問題ない、と書けば満足ですか?
あなたが数学に詳しくても実世界の適用例に詳しくない上、言葉遣いは最悪で自分の言いたいことをここの方々にまともに説明できてないこともわかりましたから。