Save one query when inserting a new post

[ozh]

The workflow when inserting a new post is the following :

1) wp_insert_post() sets a few vars (post type, post status, ...), updates $wpdb->posts, then calls wp_set_post_categories()

2) first thing wp_set_post_categories() wants to know is $post_type and $post_status, for which it performs an SQL query, instead of getting this info from caller function

Same things goes for wp_insert_attachment()

Patch passes extra optional parameters $post_type and $post_status to wp_set_post_categories(), to save one query when adding a post, or a whole bunch when importing a batch.

[ozh]

fix wp_insert_attachment() as well

[ozh]

sorry, coding standards... tabs, not spaces

[DrewAPicture]

This seems pretty straightforward. We're also now ​always using braces on all if statements.

[ozh]

More coding standards: braces on all if

[ozh]

(why 3.0 ?)

[johnbillion]

The issue was introduced in version 3.0 ([13184] and [14883]).

[wonderboymusic]

The patch does not apply and seems to ignore all of the changes made in 4.0 (extract() removal, et al)

…st_status, to the wp_set_post_categories()` function. The intention is to improve performance by avoiding redundant database calls when the post type and status are already known.

Trac ticket:

[pbearne]

Hi all

I refreshed the patch and added tests.

But the tests don't show a saving in DB calls.
I support that the new post is still in the object cache, so the saved calls don't now hit the DB

As such, I will close the tick as it won't fix unless someone else can see the DB saving with the patch

[peterwilsoncc]

@pbearne Running clean_post_cache() before calling wp_set_post_categories() shows a difference in the number of database queries: six are made when the calling the latter with the post details provided, nine are made without.

[westonruter]

I don't think this will be a good idea. In practice, the WP_Post may already be in the object cache, as evidenced by the performance improvement confusion when testing. Also, this relies on the caller providing the $post_type and $post_status that match whatever is for the provided $post_id. What if you provide something that is inconsistent? There's no longer a source of truth which we get by just relying on the $post_id. I concur that this should be closed.

[westonruter]

Actually, reading the ticket description, I now see this:

2) first thing wp_set_post_categories() wants to know is $post_type and $post_status, for which it performs an SQL query, instead of getting this info from caller function

Maybe a better approach would be to call update_post_cache() so that when wp_set_post_categories() runs it has access to to the post_type and post_status in the object cache?

[peterwilsoncc]

Replying to westonruter:

Maybe a better approach would be to call update_post_cache() so that when wp_set_post_categories() runs it has access to to the post_type and post_status in the object cache?

The call to get_post_type() already primes the cache (via get_post via WP_Post) so calling update_post_cache() will result in the same number of queries, the location would just change.

However, looking at wp_insert_post() even with this change the post will end up being queried with the call to $current_guid = get_post_field( 'guid', $post_id ); so passing the data to wp_set_post_categories() may not have an effect on the number of queries anyway.

[ozh]

LOL. Seriously, people, this report is _12 years old_ and there was a patch. Why not close it at this point?