trepmal / wp-revisions-cli

WP-CLI command. Manage post revisions.
MIT License
152 stars 22 forks source link

--hard is (very) slow #10

Open drzraf opened 6 years ago

drzraf commented 6 years ago

Sample database (lines, size in MB)

| wp_postmeta                  | 418795 | 101.83 |
| wp_posts                     |   5235 |  11.67 |  ### (3030 are revisions)

Then individual DELETE are runs which is very slow:

Cleaning revisions for 627 post(s)  90 % [===================================>        ] 22:34  / 181:48
Cleaning revisions for 627 post(s)  98 % [==========================================> ] 55:36 / 1:38
Cleaning revisions for 627 post(s)  100% [============================================] 64:39   #### 1 hour
| wp_postmeta                  | 27107 | 8.55 |
| wp_posts                     |  3232 | 3.02 |
  1. because wp_delete_post_revision basically does:

    wp_get_post_revision( $revision_id )
    wp_delete_post( $revision->ID );
    do_action( 'wp_delete_post_revision', $revision->ID, $revision );
  2. And that wp_delete_post itself is slow.

Could we think about a --quick which simply DELETE FROM {postmeta} WHERE post_id IN ( implode( <deleted_post_id> ) ) ?

tapetersen commented 4 years ago

I see the same problem but I do understand that the hard option really needs to go through the hooks as that is the best way to guarantee compatibility with other themes and plugins.

The current option of not using --hard is however really problematic as it's leaving behind a lot of orphaned metadata for the posts which in may cases are actually the main data size that we want to remove with the revisions.

If acceptable as a good idea I could provide a PR dropping the metadata along with the posts when using the normal quick path (I don't see a reason to keep the variant where only postdata and not postmeta is deleted).

drzraf commented 4 years ago

Somehow related: https://core.trac.wordpress.org/ticket/34848