Changes between Version 1 and Version 2 of Ticket #33973, comment 1
- Timestamp:
- Sep 1, 2022, 11:12:48 AM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33973, comment 1
v1 v2 1 1 After more digging, it appears that the two worst culprits in my query are the 1st and 3rd `Exists`. The 1st is about 10x slower on 3.2.15 than on 3.1.14. The 3rd is about 6x slower on 3.2.15 than on 3.1.14. The execution times for the 2nd and 4th `Exists` are about the same for 3.2 and 3.1. 2 2 3 If I use only the 1st `Exists` in my query, by commenting out the 3 others, and by adding a False for the `Greatest` requirement of min 2 args, I obtain de following explanations(I also removed the `order_by` and `select_related` clauses to simplify the query as much as possible):3 If I use only the 1st `Exists` in my query, by commenting out the 3 others, and by adding a False for the `Greatest` requirement of min 2 args, I obtain de following **explanations** (I also removed the `order_by` and `select_related` clauses to simplify the query as much as possible): 4 4 5 On Django 3.1.14:5 **On Django 3.1.14**: 6 6 7 7 {{{ … … 44 44 }}} 45 45 46 On Django 3.2.15:46 **On Django 3.2.15**: 47 47 48 48 {{{ … … 76 76 }}} 77 77 78 So it appears that the strategies of the two Django versions are indeed not the same. And it also appears that the regression stems from the implementation of the `exclude(threadentry__user=user)` clause.78 So it appears that the SQL strategies of the two Django versions are indeed not the same. And it also appears that the regression stems from the implementation of the `exclude(threadentry__user=user)` clause (reverse traversal of the thread entry FK). 79 79 80 80 Hope this info can help a gourou isolate the problem source (SQL optimization is out of my league).