[wp-trac] [WordPress Trac] #61097: Filter `wp_count_posts()` query before execution to avoid slow query

[WordPress Trac]

#61097: Filter `wp_count_posts()` query before execution to avoid slow query
-------------------------------------------------+-------------------------
 Reporter:  rcorrales                            |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.9
Component:  Posts, Post Types                    |     Version:  2.5
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |  performance
-------------------------------------------------+-------------------------

Comment (by SirLouen):

 Replying to [comment:20 westonruter]:
 > I asked Gemini to evaluate the old query compared with the new query for
 whether they are equivalent and why the UNION ALL version would be more
 efficient. What follows is the response:

 >Yes, the two queries are logically equivalent, and the second version
 using UNION ALL is generally more efficient.

 [[Image(https://i.imgur.com/XAe1uXc.png)]]
 [https://core.trac.wordpress.org/ticket/61097?replyto=20#comment:16
 Thorough performance testing]
 [https://core.trac.wordpress.org/ticket/61097?replyto=20#comment:19 AI's
 Opinion]

 By the way, who in the world asks Gemini, having Claude available? Are you
 on Google's marketing team now? xD

 > The [https://github.com/WordPress/wordpress-develop/pull/9772 PR] looks
 good.
 >
 > I do have a question on whether the new filter is needed, however.
 Originally it was proposed as a way to fix the problem if the SQL query
 wasn't optimized. But the optimization with `UNION ALL` is applied. So is
 the filter still needed?

 Yep, I also thought the same while building the test, you asked me. The
 test looked very awkward, like, "build your own query within this
 function." I tried to put an example of a query that could make sense
 (counting children), which you could easily conclude that i could be
 executed anywhere without the filter… But @johnbillion asked @rcorrales
 back in the day to open a new ticket just for this, so I did not think
 deeply about the reason behind this and just added the amazing filter.

 Conclusion: I also believe that the filter should go, and I've removed it
 from the PR. If anyone wants a filter in the future, open a new ticket

 So the patch is ready to be shipped now.

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