Corner case for add_path_precheck - Mailing list pgsql-hackers

From Antonin Houska
Subject Corner case for add_path_precheck
Date
Msg-id 17553.1423517007@localhost
Whole thread Raw
Responses Re: Corner case for add_path_precheck
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: sloppy back-patching of column-privilege leak
Next
From: Ravi Kiran
Date:
Subject: enabling nestedloop and disabling hashjon