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 and then do a fuzzy
         * cost comparison with very small fuzz limit.
         * (We used to do an exact cost comparison,
         * but that results in 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
         * comparison decides 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 dominates new */
        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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to