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