Opened 7 years ago
Closed 3 years ago
#39716 closed enhancement (invalid)
Improve update_meta_cache's performance when called with one object ID
Reported by: | macprawn | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.8 |
Component: | Options, Meta APIs | Keywords: | close |
Focuses: | performance | Cc: |
Description
When update_meta_cache is called with only one object ID, the SQL statement using "WHERE $column IN ($id_list)" is not optimized and could be much faster as "WHERE $column=$id_list".
Change History (6)
#2
@
7 years ago
- Keywords reporter-feedback added; 2nd-opinion removed
That's correct, it should be optimised away when only one value is passed.
@macprawn: Do you have any examples where this isn't the case?
#3
follow-up:
↓ 4
@
7 years ago
- Keywords reporter-feedback removed
Thanks guys - first time contributing here, so please let me know if I'm doing it wrong...
@pento yes, I do have an example:
wp-includes/meta.php, line 826
As more and more people use custom fields, this can become problematic when you have to "get_post_meta" repeatedly, in a loop or multiple times to access multiple custom fields for this one post.
Thanks!
#4
in reply to:
↑ 3
;
follow-up:
↓ 5
@
7 years ago
https://github.com/WordPress/WordPress/blob/master/wp-includes/meta.php#L826
Replying to macprawn:
Thanks guys - first time contributing here, so please let me know if I'm doing it wrong...
@pento yes, I do have an example:
wp-includes/meta.php, line 826
As more and more people use custom fields, this can become problematic when you have to "get_post_meta" repeatedly, in a loop or multiple times to access multiple custom fields for this one post.
Thanks!
#5
in reply to:
↑ 4
@
7 years ago
Awesome, thank you for that. I will use that format in the future.
Replying to lukecavanagh:
https://github.com/WordPress/WordPress/blob/master/wp-includes/meta.php#L826
#6
@
3 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
Closing this ticket. Why? As noted, the performance here will be the same between IN(1)
and =1
and the trade-off of additional code adds complexity.
The MySQL query optimizer (which runs on all queries regardless) will optimize a IN(1) and =1 query the same way AFAIK, branching in PHP to perform a separate code branch here is unlikely to save any significant CPU time in the scheme of performing a query but would certainly add code and debugging complexity for future maintainers.
Hi @macprawn and welcome to Trac!
This is quite possibly an optimisation that won't actually speed anything up, @pento what's your thoughts?
The MySQL query optimizer (which runs on all queries regardless) will optimize a
IN(1)
and=1
query the same way AFAIK, branching in PHP to perform a separate code branch here is unlikely to save any significant CPU time in the scheme of performing a query but would certainly add code and debugging complexity for future maintainers.