[wp-hackers] Options table' varchar 64.
morgan.tocker at oracle.com
Tue Jun 24 18:37:14 UTC 2014
> So, assuming if it's a 100 site, multi-site network where each site has as
> many options as you described, this one time pain of schema change will
> come at the expense of a 2.87*100 sec?
On my blog, I only have 163 rows in wp_options, but in my test I generated 104994 rows of dummy data.
(Others will have more than 163 rows - I am probably a simple use case.)
> Is this understanding correct in a nut-shell?
I tried to create the test so any skew showed closer to the worst-case than the best case. This is not always easy to do, and I can already identify two cases where this will not be true:
- My local machine is more powerful than virtual machines / VPS hosting environments.
- There might be some very long option_value texts creating a larger table. I used REPEAT('a', 200), but should have probably gone for REPEAT(‘a’, 1889), as this is the average option_value length in my installation.
TL;DR: I think it will be less than 2.87*100. You can try it for yourself though:
More information about the wp-hackers