Make WordPress Core

Changes between Initial Version and Version 34 of Ticket #15499


Ignore:
Timestamp:
06/13/2022 05:37:08 AM (4 years ago)
Author:
mukesh27
Comment:

Hi there!

@simonwheatley PR updated against the Trunk version can you please test if it works for you?

@SergeyBiryukov is this ticket is in your to-do list? Do you think it will marge in the upcoming release?

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15499

    • Property Status changed from new to reviewing
    • Property Focuses performance added
    • Property Owner set to SergeyBiryukov
    • Property Milestone changed from Awaiting Review to Future Release
  • Ticket #15499 – Description

    initial v34  
    1 I had a friend (Jools Wills) look over a WordPress site recently, to get a fresh view on what might be optimised, and he noticed a query which might benefit from an additional index on ```WP_Posts```. The query ```SELECT post_modified_gmt FROM $wpdb->posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_modified_gmt DESC LIMIT 1``` in ```get_lastpostmodified``` is run for last modified date in GMT, and currently doesn't use an index. This SQL is run whenever certain types of feed are requested as far as I can see.
     1I had a friend (Jools Wills) look over a WordPress site recently, to get a fresh view on what might be optimised, and he noticed a query which might benefit from an additional index on `WP_Posts`. The query `SELECT post_modified_gmt FROM $wpdb->posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_modified_gmt DESC LIMIT 1` in `get_lastpostmodified` is run for last modified date in GMT, and currently doesn't use an index. This SQL is run whenever certain types of feed are requested as far as I can see.
    22
    3 We added ```CREATE INDEX type_status_modified ON wp_posts (post_type, post_status, post_modified_gmt);``` and ```CREATE INDEX type_status_modified_no_id ON wp_posts (post_type, post_status, post_date_gmt);``` and the query runs a lot faster now. The following timings were taken running the first query (```post_modified_gmt```) on a 36,362 row posts table. Note that it doesn't use filesort after the index has been added.
     3We added `CREATE INDEX type_status_modified ON wp_posts (post_type, post_status, post_modified_gmt);` and `CREATE INDEX type_status_modified_no_id ON wp_posts (post_type, post_status, post_date_gmt);` and the query runs a lot faster now. The following timings were taken running the first query (`post_modified_gmt`) on a 36,362 row posts table. Note that it doesn't use filesort after the index has been added.
    44
    55''Before:''
     
    4040 * 0.00066208839416504ms
    4141
    42 In ```get_lastpostmodified``` both these queries are run, so the total savings in my case on a quiet server are nearly 0.5 seconds... worth having, I reckon.
     42In `get_lastpostmodified` both these queries are run, so the total savings in my case on a quiet server are nearly 0.5 seconds... worth having, I reckon.
    4343
    44 I've not created a patch for schema changes before, but I think the only place the change would need to go would be ```scheme.php```? Suggested patch attached.
     44I've not created a patch for schema changes before, but I think the only place the change would need to go would be `scheme.php`? Suggested patch attached.