start_post_rel_link() makes 3 DB queries; too much for what it offers

[demetris]

I think 3 DB queries is far too much for what start_post_rel_link offers (printing in the doc HEAD a relational link to the first post of the blog).

Is this function (or the one it uses, or the one that uses) as optimal as we can get it?

If yes, isn’t there anything else we can do about that? Like, say, storing the value as an autoloaded transient option?

[demetris]

adjacent_posts_rel_link_wp_head is worse.

When on a Page, i.e. on a post of the page type, it seems to be making up to 9 queries to do its job.

[dd32]

See also: #15028 - Removed the term & postmeta queries related to the posts queried.

[demetris]

Thanks, dd32!

As far as I can tell, r15701 brings a huge improvement:

start_post_rel_link now takes 1 query. (It took 3 before.)

adjacent_posts_rel_link_wp_head for posts of type page now takes up to 4 queries. (It took up to 9 before.)

[dd32]

adjacent_posts_rel_link_wp_head for posts of type page now takes up to 4 queries. (It took up to 9 before.)

Can you paste the queries? (Ie. is it anything more than > POST_DATE LIMIT 1, and < POST_DATE LIMIT 1?)

[demetris]

Maybe I was wrong when I said adjacent_posts_rel_link_wp_head added 4 queries, because I cannot reproduce that again. Now I see it adding three (3) queries.

The two are for post_date, as you said. E.g.:

SELECT p.* FROM wp_posts AS p
WHERE p.post_date < '2010-02-28 14:28:19' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date DESC LIMIT 1

SELECT p.* FROM wp_posts AS p
WHERE p.post_date > '2010-02-28 14:28:19' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date ASC LIMIT 1

The third extra query is like this:

SELECT `post_parent` FROM wp_posts WHERE ID = 534 LIMIT 1

Which seems to run a second time when adjacent_posts_rel_link_wp_head is on.

(Here is how I check, in case I do something wrong: I first comment out all four rel nav actions in default-filters.php. Then I switch them individually and watch the queries with the SQL Monitor plugin.)

[dd32]

Cheers, i'll have another look at that, i'll see if i can spot why that 3rd query is running multiple times..

[demetris]

Replying to demetris:

The third extra query is like this:

SELECT `post_parent` FROM wp_posts WHERE ID = 534 LIMIT 1

Which seems to run a second time when adjacent_posts_rel_link_wp_head is on.

I confirmed that this third query appears with the default theme too. (Just wanted to make certain it was not something wrong with my own theme, and that I did not bother people with non-existent issues.)

[jeremyclarke]

+1 for making the rel links require less queries. I had no idea they were there until I had to reverse engineer their presence based on the inane queries they generate (which were clogging my MySQL queue during a high-stress/outage period).

All of these queries are simple and relatively fast if everything is okay, but as far as I can tell on my database (>60k published posts and >250k rows in wp_posts) ANY queries affecting wp_posts contribute to a cpu trashing everything-is-broken state.

Caching such things in a transient is probably a good idea, espcially the 'start' one, which will never ever ever change after the blog is installed. Having a query on every single.php for it is nuts.

[Elpie]

Please also see https://core.trac.wordpress.org/ticket/18128

Everything except link rel='prev' and link rel='next', that are output by adjacent_posts_rel_link_wp_head, are unsupported by browsers and assistive technologies. In the HTML5 spec they are explicitly not allowed. In XHTML and older versions of HTML they do nothing so the number of queries can be reduced by removing the superfluous link types.

[nacin]

Closing as a duplicate then. Let's deal with this in #18128.