Thread: are the 2 if-statements in join_is_legal() removable?
Hi:
In join_is_legal(), there are 2 decision-making statements based on match_sjinfo. I wonder wether their conditions can ever test possitive.
/*
* If one input contains min_lefthand and the other contains
* min_righthand, then we can perform the SJ at this join.
*
* Reject if we get matches to more than one SJ; that implies we're
* considering something that's not really valid.
*/
if (bms_is_subset(sjinfo->min_lefthand, rel1->relids) &&
bms_is_subset(sjinfo->min_righthand, rel2->relids))
{
if (match_sjinfo)
return false; /* invalid join path */
match_sjinfo = sjinfo;
reversed = false;
}
else if (bms_is_subset(sjinfo->min_lefthand, rel2->relids) &&
bms_is_subset(sjinfo->min_righthand, rel1->relids))
{
if (match_sjinfo)
return false; /* invalid join path */
match_sjinfo = sjinfo;
reversed = true;
}
There is no query in regression test suite that can render the 2 decision-makings based on match_sjinfo true, nor can i figure out one. Can these conditions ever be true? If they can be true, what queries can make them true? On the contrary,if the conditions can never be true, then the 2 "if (match_sjinfo) return false" statements can be safely removed.
Any feedback is welcome.
--
Best Regards
Geng
g l <orangegrove@live.com> writes:
> Then I run the core regression tests with "make installcheck-parallel
> " for v18beta1 as the document dictates. When the regression test is done, only the last 2 log entries are found in
logfile,the first 2 entries are not printed at all. I run core regression also with v14.15 and v17.2, the results are
thesame. What test suite do I need to run to cover the first 2 branches, or could you please show me a example query
thatcan cover them? Thank you very much.
The coverage.postgresql.org results are, I believe, for check-world
not just the core tests. You might try contrib/postgres_fdw first,
as that tends to be the non-core test with the most planner coverage.
In any case, the fact that a few of these lines are not reached by
test cases doesn't constitute a bug, and it most certainly doesn't
mean it'd be safe to remove them. Most of the logic in join_is_legal
comes in symmetrical pairs of cases for the two possible orderings
of the two input relations. It's just coincidental which of a pair
of cases will be exercised by a given phrasing of a SQL query.
So I don't feel that we're particularly short on coverage here:
one or the other code path is fully exercised in each case,
according to the coverage.postgresql.org results.
regards, tom lane