DragonByte Tech
Well-known member
There has been only one other report of this, the vast majority of people see the transaction page load instantly.
What version of MySQL are you running?
![[DBTech] DragonByte Credits](/community/data/resource_icons/5/5871.jpg?1592168428){kind=icon}
[DBTech] DragonByte Credits [Paid] 6.0.9
- Thread starter DragonByte Tech
- Start date
What version of MySQL are you running?
ShinLim
Active member
Not really, i'm facing with this problem too, it took 7-8 seconds to load the page, even 10 seconds
Mine has more than 5000 pages, which every page has 25 transactions
That's pretty slow, i hope you could improve it, took me so long everytime i want to access transactions page
DragonByte Tech
Well-known member
ShinLim
Active member
MySQL version5.5.5 (10.4.7-MariaDB)
DragonByte Tech
Well-known member
I'm developing on 10.3 locally, I'll try to upgrade to 10.4 to see if I can reproduce the issue.
DragonByte Tech
Well-known member
Can confirm this issue exists on 10.4. If possible, I would consider reverting to 10.3 until this could be resolved.
DragonByte Tech
Well-known member
This appears to be a bug in MariaDB 10.4:
Notice how the Currency join doesn't use the primary key? Every other JOIN table does. I don't believe this is a problem with my database setup, as it worked fine in MariaDB 10.3.
DragonByte Tech
Well-known member
You'll need to downgrade to 10.3. I don't believe there's anything I can do, the optimiser is clearly broken in 10.4.
DragonByte Tech
Well-known member
After some searching, I found you can disable the bugged feature temporarily with:
SQL:
SET GLOBAL join_cache_level=0;
Code:
join-cache-level = 0Do this at your own risk.
Last edited:
ShinLim
Active member
I don't know "join_cache_level=0" what it could impact to, so I can't risk it, also I'm not very good at stuffs like downgrade, I have to read instructions and do step by step to upgrade it, now if I downgrade, that would be a challenge for me
DragonByte Tech
Well-known member
Then there is no way for you to avoid this bug in MariaDB. There is no problem with my query, this is a server side issue.
ShinLim
Active member
Could you try to find out a little bit more and try to flexible with it?
DragonByte Tech
Well-known member
Sorry I'm not sure I understand, can you clarify please?
ShinLim
Active member
I mean could you try to find how to adapt with MariaDB 10.4 version by add/edit your code in someway to fix this bug?
DragonByte Tech
Well-known member
It just so happens that this time, I have been able to find a workaround thanks to Xon's help.
As a general note though, it is worth bearing in mind that you installed broken software on your server (MariaDB 10.4 - related bug report: https://jira.mariadb.org/browse/MDEV-16337 ) and you cannot reasonably ask add-on authors to fix or mitigate issues resulting from installing broken software on your server.
What if making changes to work around the broken software you installed caused horrendous performance for everyone else? Then I would have to decide between you two having good performance and everyone else having terrible performance, or vice versa.
In short: It is not up to add-on authors to "be flexible" when the problem is a server-side software problem. It is up to the server administrator to not install broken software in the first place. If they have already deployed the broken server-side software, it is up to the server administrator to work out a plan to roll back to the last known good configuration of the server-side software.
If you don't use the "Frequency" option for any of your events then it may be safe to do so. I would recommend backing the table up before doing anything with it.
You may also wish to wait for the update that works around the bug in MariaDB 10.4.
DragonByte Tech
Well-known member
I don’t know what you mean by that, sorry. Can you clarify, please?
Similar threads
