[wp-trac] [WordPress Trac] #33885: meta_form performs a potentially expensive query

[WordPress Trac]

#33885: meta_form performs a potentially expensive query
-------------------------------------+-----------------------------
 Reporter:  jorbin                   |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Administration           |     Version:  4.3.1
 Severity:  critical                 |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by pento):

 Unfortunately, I don’t see MySQL/MariaDB allowing sorting by partial
 indexes any time soon (and certainly not back porting it to older
 versions), which means we need to implement something in WordPress.

 I don’t like the option of making `meta_key` shorter, as we’ll either end
 up truncating existing data, or (if we check for longer values before
 truncating) have some sites with `meta_key` as `VARCHAR(191)`, and some
 with it as `VARCHAR(255)`. Diverging database structures makes ongoing
 maintenance much more difficult, which I would prefer to avoid. That
 leaves the remaining options of more explicitly recommending the
 `postmeta_form_keys` filter, removing the meta box, or caching the query
 result.

 I don’t think that the `postmeta_form_keys` filter is the right solution,
 particularly for sites that have regularly changing meta keys. We’d
 effectively be asking folks to write their own caching solution.

 Removing the meta box is probably a big task that will involve a lot of
 ongoing work unrelated to this particular ticket. Ultimately, that’s the
 right solution, but I’m not sure if it’s something we should tackle to
 solve this bug.

 That leaves caching the query result. Now, we can either cache using
 `WP_Object_Cache` (so the cache is really only valuable to sites with a
 persistent caching setup), or cache the results in an option, so that it’s
 valuable to any site. I lean towards using the object cache, as the usual
 caching solution, but I’m open to arguments either way.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33885#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform