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