> 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
