Eu acho que agora eu entendo o que você está tentando fazer. Quando você executa uma consulta personalizada WP_Query
e define o limite para obter apenas 5 postagens por página, apenas 5 postagens serão recuperadas pela consulta e essa consulta retém apenas 5 postagens, MAS , por uma questão de paginação, WP_Query
ainda é executada em todo o banco de dados e conta todas as postagens que correspondem aos critérios da consulta.
Isso pode ser visto quando você olha para as propriedades $found_posts
e $max_num_pages
da consulta. Vamos dar um exemplo:
Você tem 20 postagens pertencentes ao tipo de postagem padrão post
. Você só precisa das 5 últimas postagens sem paginação. Sua consulta tem esta aparência
$q = new WP_Query( 'posts_per_page=5' );
var_dump( $q->posts )
fornecerá as últimas 5 postagens conforme o esperado
echo $q->found_posts
Darei à você 20
echo $q->max_num_pages
Darei à você 4
O impacto desse trabalho extra é mínimo em sites com apenas algumas postagens, mas isso pode custar caro se você estiver executando um site com centenas ou milhares de postagens. Isso é um desperdício de recursos, se você precisar apenas das 5 últimas postagens
Existe um parâmetro não documentado chamado no_found_rows
que usa valores booleanos que você pode usar para fazer sua consulta ser resgatada após encontrar as 5 postagens necessárias. Isso forçará a WP_Query
não procurar mais postagens que atendam aos critérios depois de recuperar a quantidade de postagens consultadas. Esse parâmetro já está incorporado get_posts
, por isso get_posts
é um pouco mais rápido do WP_Query
que o get_posts
uso deWP_Query
Conclusão
Em conclusão, se você não usar a paginação em uma consulta, é sempre aconselhável 'no_found_rows=true'
em sua consulta acelerar as coisas e economizar em desperdiçar recursos.
'posts_per_page=5'