Timeline for Why is the PostgreSQL Query Planner choosing such an inefficient solution?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2023 at 15:57 | vote | accept | kylejw2 | ||
| Aug 14, 2023 at 21:00 | comment | added | jjanes | The problem is not that 1/4 don't have projects, the problem is that that 1/4 are all at one end of the ORDER BY. As I said, it simply assumes the qualifying rows are randomly scattered long the ORDER dimension, it is not really an estimation, just an assumption. This pro-rating is implemented in adjust_limit_rows_costs, so you could comment out those call sites if you wanted. | |
| Aug 14, 2023 at 16:53 | comment | added | kylejw2 | I won't get into the business details, but it suffices to say that it makes sense that a quarter of the tasks don't have a project. I tested your fix and it did work. Thank you for that. Unfortunately, this doesn't address the root problem of the query planner. Do you have any insights on why the query planner is drawing inaccurate conclusions? Or do you have any advice on how to further investigate the issue? | |
| Aug 12, 2023 at 1:43 | history | answered | jjanes | CC BY-SA 4.0 |