Hi @grzegorzjanoszka
Since 2.9.3, all direct WordPress database calls have been replaced in the plugin in favor for WordPress’ own cached calls, aside from a debugging script (disabled by default) and WPMUdev Domain Mapping compatibility.
You describe “Since the moment”:
Might this be a fluke as WordPress updates its cache when a plugin updates?
Are you still encountering these table writes, and are they causing performance issues?
I’d love to hear back from you. Cheers!
Sybre, there is a clear pattern to that. I can send you vie email graphs of my mysql parameters, so you can take a look.
Hi @grzegorzjanoszka,
That would be great!
I’m most interested in what the tmp_disk_tables
contain. I suspect it has something to do with taxonomical cache, which is maintained by WordPress but might never be fully initiated by it.
Could you also tell me if the transient cache options are enabled?
Thanks! 🙂
Graphs sent, I hope you will get them. I am not sure how I can get the content of those tables. I played with the first two transient options, but there was no change in the mysql graphs.
Thanks for the graphs @grzegorzjanoszka!
On GitHub, there’s a similar issue report:
https://github.com/sybrew/the-seo-framework/issues/167
On that issue, I’ll write up a snippet to see if it helps mitigate the issue.
If it does, I’ll turn it into a temporary option until I can find a way to deal with this permanently.
Sybre, I am ready to test the new code. Let me know when you have it.
It’s there @grzegorzjanoszka 🙂
Let me know if it resolves the issue, as we then know where it resides. Cheers!
So far it looks like it really fixed it. My temp tables numbers are back to normal.
Thank you!
I understand we can expect a fix in the further release of this great plugin?
I’m glad to hear it works 🙂
Yes, you can expect a patch first, and then a permanent fix.
So far it seems this issue is only affecting massive websites, where large JOIN/GROUP clauses cause SQL overhead on archival pages.