Thanks for the question. The performance gains can be subtle, and depend on the kinds of things happening in your site.
Plenty of folks see big gains. I wrote the plugin for a WooCommerce store I maintain, and I see big gains.
You might try using a persistent object cache if you need better gains than you see now. https://developer.ww.wp.xz.cn/reference/classes/wp_object_cache/#persistent-cache-plugins
If I can help you further, please upload your metadata following the instructions in the pinned topic on this forum.
Thread Starter
hurry
(@extremist87)
Hey there
I’ve enabled redis object cache and also used your plugin to index the tables along with using wp optimize to optimize and clean up the tables. My database is 2.5gb. I read up online and people say that size isn’t the problem so not sure what else to try
I’d like to see your metadata to help you further.
This plugin makes a very big difference when you have hundreds of sites on a single server. I have a cPanel site with about 120 accounts on it, and this plugin has put some real pep in the old girl’s step.
That said, I had made an error in my app that wasn’t immediately apparent to me. Check this out:
$appointments = $wpdb->get_results("SELECT * FROM $meta_table WHERE meta_key = 'appt_timestamp' && meta_value = $timestamp");
Meta values are always strings, but if $timestamp IS AN INTEGER, then you get a full table scan and the query will crush your db server. All I had to do was add single quotes around $timestamp:
$appointments = $wpdb->get_results("SELECT * FROM $meta_table WHERE meta_key = 'appt_timestamp' && meta_value = '$timestamp'");
I searched my entire app for “meta_value = $” and fixed less than 10 instances. It cut my database load in half. If you’re doing fancy searches you can create indices based on multiple columns as well.
Thanks for the followup. You’re quite right about the meta_value = integer filtering. The WP_Meta_Query code does handle this use case as well as the wonderful stringly-typed metadata tables allow.
And, beware, searching for equality rather than a range on timestamps is an error-prone procedure. Off by one second means no results.
Thanks again for the followup. I bet this problem would have showed up in Query Monitor or in one of the monitors in this plugin.
Please don’t hesitate to start another thread if I can help further.
