Thread: Repeat the condition check twice in function distribute_qual_to_rels
Repeat the condition check twice in function distribute_qual_to_rels
From
"bigbro_wq@hotmail.com"
Date:
Hi,
I notice that check the condtion again when after invoked process_equivalence and return failed.
if (restrictinfo->mergeopfamilies)
{
if (maybe_equivalence)
{
if (process_equivalence(root, &restrictinfo, jtitem->jdomain))
{
/* distribute to base */
int relid;
if (bms_get_singleton_member(restrictinfo->required_relids, &relid))
{
restrictinfo->fromec = true;
distribute_restrictinfo_to_rels(root, restrictinfo);
}
return;
}
/* EC rejected it, so set left_ec/right_ec the hard way ... */
if (restrictinfo->mergeopfamilies) /* EC might have changed this */
initialize_mergeclause_eclasses(root, restrictinfo);
/* ... and fall through to distribute_restrictinfo_to_rels */
}
-----------------------------------------------------------------------------------
Above the codes, check the condition again when invoked process_equivalence failed,
but it's already under the positive condition "if (restrictinfo->mergeopfamilies)".
It's necessary ?
bigbro_wq@hotmail.com
"bigbro_wq@hotmail.com" <bigbro_wq@hotmail.com> writes:
> I notice that check the condtion again when after invoked process_equivalence and return failed.
> /* EC rejected it, so set left_ec/right_ec the hard way ... */
> if (restrictinfo->mergeopfamilies) /* EC might have changed this */
> Above the codes, check the condition again when invoked process_equivalence failed,
> but it's already under the positive condition "if (restrictinfo->mergeopfamilies)".
> It's necessary ?
Yes. See commit 8ec5429e2: the restrictinfo might now be
completely different from what it was.
(You could have discovered this for yourself by removing
the test and seeing what happened.)
regards, tom lane