4 ms·
No, you are correct, it's just hard to debug something and produce a minimal case when the only change is "performance bad". This is mostly a hint to people tha
by summarity 3y ago
No, you are correct, it's just hard to debug something and produce a minimal case when the only change is "performance bad". This is mostly a hint to people that may run into similar issues while upgrading.
And my reference concerned this comment (which I may have misunderstood, sorry if that's the case):
> It is not planned for any patch releases because it is only a performance issue and not a malfunction.
- TheRealPomax 3y agopatch releases are the third number (e.g. the "1" in "3.43.1"). The comment says nothing about it not qualifying as work to be done for a minor release (e.g. the "43" in "3.43"). If the bug is closed, and you still see it happening, file a new bug with a reproducible example so that the maintainers know it's (still) happening. And if that example means setting up a small dedicate repo with enough data to show the problem off, that's probably worth doing.
- nextaccountic 3y ago> No, you are correct, it's just hard to debug something and produce a minimal case when the only change is "performance bad". Well the sqlite devs should be aware of your specific test case (the specific query that is still 3 orders of magnitude slower). Are they? After this the ball is with them