> Certainly, "NaN means infinity", as your patch proposes, has no more basis to it than "NaN means zero".
You are absolutley right. Now I see that best interpretation is "NaN
means NaN". Seems like we need only drop a check. Nodes with NaN
penalties will be considered even worser than those with infinity
penalty.
Penalty calculation is CPU performance critical, it is called for
every tuple on page along insertion path. Ommiting this check will
speed this up...a tiny bit.
> If the penalty function doesn't like that interpretation, it shouldn't return NaN.
It may return NaN accidentally. If NaN will pass through union()
function then index will be poisoned.
That's not a good contract to remember for extension developer.
Regards, Andrey Borodin.
