Ludiaのインデックスコスト計算がおかしい

PostgreSQLにSennaをくっつけた、Ludiaというソフトウェアがあります。

知らぬ間に1.4をリリースしていたらしい。おめでとうございます。
先日、不可解な現象を発見したのでメーリングリストに投げたのですが、
インデックスコスト推定関数について (Ludia-users 83) - Ludia - SourceForge.JP
要するに、インデックスコストがマイナスになるためにポスグレちゃんが自暴自棄になって
逆走を始めてしまう、という極めて危険な例でした。

原因は下記Ludiaソースにあって、

*indexTotalCost += -DEFAULT_RANDOM_PAGE_COST;

とあって、未だに解せませぬ。この計算、indexTotalCostが0未満になりえる可能性がある時点でまずいと思うべきなのですが。

PostgreSQLのドキュメントを読む限り、

インデックスアクセスコストはsrc/backend/optimizer/path/costsize.cで使われる、順番に並んだディスクブロックの取り出しにはseq_page_costのコストが、順不同の取り出しにはrandom_page_costのコストが、そして、1つのインデックス行の処理には通常 cpu_index_tuple_costというコストがかかる、というパラメータで計算されなければなりません。さらに、インデックス処理（特にindexQuals自身の評価）の間に呼び出される比較演算全てに対して、cpu_operator_costに適当な係数をかけたコストがかかります。

とあり、明らかにこれは「掛け算」すべき係数です。なぜNTTデータの中の人が「引き算」しているのか、まったくわからない。

どっかでそういう例があるのかと思ってソースも読んでみたのですが、

		/*
		 * Now compute the total disk access cost, and then report a pro-rated
		 * share for each outer scan.  (Don't pro-rate for ScalarArrayOpExpr,
		 * since that's internal to the indexscan.)
		 */
		*indexTotalCost = (pages_fetched * random_page_cost) / num_outer_scans;

となっていて、引き算の例はないのです。
まあその辺は、作っている人の事情とやらがわかっていないのかもしれませんが、

コスト計算 - Ludia開発日記

設定でユーザに責任を委ねるっていうのはいかがだろう。
そんなインデックス、聞いたことないんですけど。

ていうか、そういう報告が他にないってことは、Ludiaってあんまり使われてないのかしらん。
まあ、全文検索を深いネストループでやる人が少ないだけかもね。