-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable all join operators for all joins for n rels if there is no join hint for n rels #208
base: PG16
Are you sure you want to change the base?
Conversation
In this comment, for these test queries which generate unexpected plans with the above modifications, I present their actual plans and expected plans. It's obviously that all actual plans has less cost, thus we may need to update the expected test results. pg_hint_plan.sql
ut-L.sql
ut-R.sql
|
Hi, the generated different plans with the above modifications are due to the plan comparison function In our case, if plan A and B are disabled paths and their actual cost are 1e7 and 2e7 respectively, then the planner will add disable_cost to their cost, and the final cost of plan A and B is 1.001e7 and 1.002e7, the function I think we should add disable_cost to the estimated cost, as fewer cases as better. Looking forward to a reply. |
Hi, I created this pull request to solve problems introduced in #207 which I will introduce later. But this pull request is independent of #207 and it only modifies several lines of code.
For a query (from a test file) with hints like
The hint only includes the join hints for join (t3 t4) and the generated plan is
In this plan, a
disable_cost
(1e10) has been added to the cost of nestloop(t2 t3 t4) and two have been added to nestloop(t1 t2 t3 t4). This is because pg_hint adds adisable_cost
to the cost of all joins without a join hint, even if there is no join hint for all joins with the same number of relations. In this example, adisable_cost
will be added to all joins with 3 relations and two will be added to all joins with 4 relations.It may be more reasonable to omit to add a
disable_cost
to all joins involving n relations if no join hint is provided for such joins. What's more, we want to enlarge thedisable_cost
to 1e20 in #207. Such a large disable_cost will lead to the wrong comparison of the costs of two disabled paths. For example, if the actual cost of the disabled path A is 12.3 and the actual cost of the disabled path B is 20, with a disable_cost (1e20), they will have the same cost because float only has approximately 15-17 decimal digits of precision. Thus, a worse path will be selected in some cases. Therefore, we should omit to add adisable_cost
to all joins involving n relations if no join hint is provided for such joins.After applying this modification, I ran the test and found some queries generated different plans with the expected. The following is one example from test
pg_hint_plan.sql
.We could see that the expected plan in the test file has a larger cost than the actual generated plan. I checked all differences and found all actual plans have less costs.So if we apply this modification, we need to update the expected plans for test sqls. I hope you apply this modification and check if you will generate different plans with the expected plans.
In summary, I want to demonstrate two things in this pull request:
disable_cost
to all joins involving n relations if no join hint is provided for such joins.Hope your reply!