Re: Retire has_multiple_baserels()
On Wed, Oct 11, 2023 at 1:13 AM Tom Lane wrote: > I thought this test wasn't too complete, because has_multiple_baserels > isn't reached at all in many cases thanks to the way the calling if() > is coded. I tried testing like this instead: > > diff --git a/src/backend/optimizer/path/allpaths.c > b/src/backend/optimizer/path/allpaths.c > index eea49cca7b..3f6fc51fb4 100644 > --- a/src/backend/optimizer/path/allpaths.c > +++ b/src/backend/optimizer/path/allpaths.c > @@ -2649,6 +2649,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo > *rel, > */ > remove_unused_subquery_outputs(subquery, rel, run_cond_attrs); > > +Assert(has_multiple_baserels(root) == > (bms_membership(root->all_baserels) == BMS_MULTIPLE)); > + > /* > * We can safely pass the outer tuple_fraction down to the subquery > if the > * outer level has no joining, aggregation, or sorting to do. > Otherwise > > and came to the same conclusion: check-world finds no cases where > the assertion fails. So it LGTM too. Pushed. Thanks for pushing! Thanks Richard
Re: Retire has_multiple_baserels()
Aleksander Alekseev writes: >> The function has_multiple_baserels() is used in set_subquery_pathlist() >> to check and see if there are more than 1 base rel, by looping through >> simple_rel_array[]. I think one simpler way to do that is to leverage >> root->all_baserels by >> bms_membership(root->all_baserels) == BMS_MULTIPLE > I used the following patch to double check that nothing was missed: > ... > It wasn't. The patch LGTM. I thought this test wasn't too complete, because has_multiple_baserels isn't reached at all in many cases thanks to the way the calling if() is coded. I tried testing like this instead: diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index eea49cca7b..3f6fc51fb4 100644 --- a/src/backend/optimizer/path/allpaths.c +++ b/src/backend/optimizer/path/allpaths.c @@ -2649,6 +2649,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel, */ remove_unused_subquery_outputs(subquery, rel, run_cond_attrs); +Assert(has_multiple_baserels(root) == (bms_membership(root->all_baserels) == BMS_MULTIPLE)); + /* * We can safely pass the outer tuple_fraction down to the subquery if the * outer level has no joining, aggregation, or sorting to do. Otherwise and came to the same conclusion: check-world finds no cases where the assertion fails. So it LGTM too. Pushed. regards, tom lane
Re: Retire has_multiple_baserels()
On Tue, Oct 10, 2023 at 5:43 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> I used the following patch to double check that nothing was missed:
>
> ```
> --- a/src/backend/optimizer/path/allpaths.c
> +++ b/src/backend/optimizer/path/allpaths.c
> @@ -2207,8 +2207,13 @@ has_multiple_baserels(PlannerInfo *root)
> /* ignore RTEs that are "other rels" */
> if (brel->reloptkind == RELOPT_BASEREL)
> if (++num_base_rels > 1)
> + {
> +
> Assert(bms_membership(root->all_baserels) == BMS_MULTIPLE);
> return true;
> + }
> }
> +
> + Assert(bms_membership(root->all_baserels) != BMS_MULTIPLE);
> return false;
> }
> ```
>
> It wasn't. The patch LGTM.
Thanks for the verification.
Thanks
Richard
Re: Retire has_multiple_baserels()
Hi,
> The function has_multiple_baserels() is used in set_subquery_pathlist()
> to check and see if there are more than 1 base rel, by looping through
> simple_rel_array[]. I think one simpler way to do that is to leverage
> root->all_baserels by
>
> bms_membership(root->all_baserels) == BMS_MULTIPLE
>
> all_baserels is computed in deconstruct_jointree (v16) or in
> make_one_rel (v15 and earlier), both are before we generate access paths
> for subquery RTEs, and it contains all base rels (but not "other" rels).
> So it should be a suitable replacement. I doubt that there would be any
> measurable performance gains. So please consider it cosmetic.
>
> I've attached a patch to do that. Any thoughts?
I used the following patch to double check that nothing was missed:
```
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -2207,8 +2207,13 @@ has_multiple_baserels(PlannerInfo *root)
/* ignore RTEs that are "other rels" */
if (brel->reloptkind == RELOPT_BASEREL)
if (++num_base_rels > 1)
+ {
+
Assert(bms_membership(root->all_baserels) == BMS_MULTIPLE);
return true;
+ }
}
+
+ Assert(bms_membership(root->all_baserels) != BMS_MULTIPLE);
return false;
}
```
It wasn't. The patch LGTM.
--
Best regards,
Aleksander Alekseev
Retire has_multiple_baserels()
The function has_multiple_baserels() is used in set_subquery_pathlist() to check and see if there are more than 1 base rel, by looping through simple_rel_array[]. I think one simpler way to do that is to leverage root->all_baserels by bms_membership(root->all_baserels) == BMS_MULTIPLE all_baserels is computed in deconstruct_jointree (v16) or in make_one_rel (v15 and earlier), both are before we generate access paths for subquery RTEs, and it contains all base rels (but not "other" rels). So it should be a suitable replacement. I doubt that there would be any measurable performance gains. So please consider it cosmetic. I've attached a patch to do that. Any thoughts? Thanks Richard v1-0001-Retire-has_multiple_baserels.patch Description: Binary data
