Comment 51 for bug 1918145

Rodolfo: Thank you for the direction. It may take me some time to get to everything, but I will work on it. The patch was formerly passing all existing TCs and I tested it to the best of my knowledge outside of our particular production use cases, but I revisit and add more TCs as needed to make sure there is full coverage for the change.

Sahid: Can you clarify on (1) and (2) in the context of the patch? The ORDER BY... in the sample queries above come from the SQLalchemy generated code in the context of the existing machinery - e.g. if you look at get_collection_query(...), it is the client/user of the library code who specifies whether or not a sort is needed for the query. We cannot unconditionally elide an ORDER BY, I think.

On your notes about the non-use of the index leading to the slowness - that is the crux of the problem here. If you look at LEDUC's former comments in this bug, there was mention of FORCE INDEX fixing the problem in some cases (I was unable to replicate a fix in Percona MySQL 5.7, though).

Going back to existing use cases of the code - I do not think removing the filter for project_id is a viable solution because it breaks existing use cases of query_with_hooks. It may make it faster, yes, but the question becomes how do we fix it without breaking existing use cases? (or, am I missing something -- if you have any code/patch to share that you'd like tested, I am more than glad to test).