Thread: Corner case for add_path_precheck

Corner case for add_path_precheck

From
Antonin Houska
Date:
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



Re: Corner case for add_path_precheck

From
Tom Lane
Date:
Antonin Houska <ah@cybertec.at> writes:
> 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?

It does, so I don't see your point?
        regards, tom lane



Re: Corner case for add_path_precheck

From
Antonin Houska
Date:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Antonin Houska <ah@cybertec.at> writes:
> > 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?
>
> It does, so I don't see your point?

Just that pre-check is - in this special (and very rare?) case - more
stringent than the proper check would be.

--
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



Re: Corner case for add_path_precheck

From
Tom Lane
Date:
Antonin Houska <ah@cybertec.at> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Antonin Houska <ah@cybertec.at> writes:
>>> 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?

>> It does, so I don't see your point?

> Just that pre-check is - in this special (and very rare?) case - more
> stringent than the proper check would be.

It's assuming that a nonzero amount of cost will be added on before the
real check happens.  Even if none was added, discarding the new path is
the way we'd break the tie that would result, so I still don't see your
point.
        regards, tom lane