Corner case for add_path_precheck

While thinking about add_path_precheck() function, it occurred to me that it
can discard some paths that otherwise would have chance be accepted in this
part of add_path():
/* * Same pathkeys and outer rels, and fuzzily * the same cost, so keep just one; to decide * which, first check rows
andthen do a fuzzy * cost comparison with very small fuzz limit. * (We used to do an exact cost comparison, * but that
resultsin annoying * platform-specific plan variations due to * roundoff in the cost estimates.)  If things * are still
tied,arbitrarily keep only the * old path.  Notice that we will keep only * the old path even if the less-fuzzy *
comparisondecides the startup and total * costs compare differently. */if (new_path->rows < old_path->rows)
remove_old= true;    /* new dominates old */else if (new_path->rows > old_path->rows)    accept_new = false; /* old
dominatesnew */else if (compare_path_costs_fuzzily(new_path, 

The special case is that the path passed to add_path_precheck() has costs
*equal to* those of the old_path. If pathkeys, outer rells and costs are the
same, as summarized in the comment above, I expect add_path_precheck() to
return false. Do I misread anything?

(Maybe the fact that this does not happen too often is that
add_path_precheck() compares the costs exactly, as opposed to the "fuzzy
comparison"?)

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at