-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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!