PostgreSQL AVEC une performance RECURSIVE

Question

J'ai une question simple. D'une manière ou d'une autre, j'étais incapable de trouver une réponse définitive.

Quelle est la syntaxe WITH RECURSIVE optimisée dans PostgreSQL? J'entends par là: est-ce simplement un sucre syntaxique pour une série de requêtes non récursives, OU est-ce plus d'une seule déclaration qui malgré sa sémantique complexe a été optimisée dans son ensemble. Une question de suivi - à quel point est-il possible d'optimiser ce type de syntaxe? Bien sûr, des données concrètes sur le sujet sont les bienvenues.

Answer 1

Mon expérience est que c'est en effet très bien optimisé.

Vérifiez le plan d'exécution pour votre requête générée par EXPLIQUEZ ANALYSER et vous verrez comment il est vraiment « coûteux » (puis comparer que par exemple à une fonction récursive auto écrite)

Answer 2

J'ai l'a trouvé optimisé jusqu'à un certain point.

Les différentes sous-requêtes sont réutilisées comme prévu et optimisées individuellement, et Postgres optimise ce dernier comme n'importe quelle autre requête. Mon principal reproche avec cela a à voir avec le fait qu'il n'injectera pas de contraintes dans les CTE quand il le pourrait.

Par exemple:

with recursive 
parents as (
select node.id, 
     node.parent_id 
from nodes as node 
union all 
select node.id, 
     parent.parent_id 
from parents as node 
join nodes as parent on parent.id = node.parent_id 
) 
select parent_id 
from parents 
where id = 2; 

Postgres comprendrait idéalement, dans ce qui précède, que (depuis node.id est retourné comme est) qu'il peut faire:

with recursive 
parents as (
select node.id, 
     node.parent_id 
from nodes as node 
where id = 2 
union all 
select node.id, 
     parent.parent_id 
from parents as node 
join nodes as parent on parent.id = node.parent_id 
) 
select parent_id 
from parents; 

... et utilisez un scan d'index sur la clé primaire. En pratique, cela fonctionnera exactement lorsque le CTE lui dira de faire: tirez récursivement tous les parents pour toutes les lignes, placez le jeu de résultats dans une table temporaire sans nom si nécessaire, puis vérifiez chaque ligne du jeu de résultats un pour id = En d'autres termes, un CTE ne garde pas une trace de l'ensemble table/ligne/colonne "originaire" qu'il retourne. Jusqu'à ce que cela soit optimisé correctement, créer une vue sur une requête récursive est au mieux fou.

Une bonne solution entre-temps est de créer une fonction sql à la place:

create function parents(id int) as returns table (id int) $$ 
    with recursive 
    parents as (
    select node.id, 
      node.parent_id 
    from nodes as node 
    where id = $1 
    union all 
    select node.id, 
      parent.parent_id 
    from parents as node 
    join nodes as parent on parent.id = node.parent_id 
    ) 
    select parent_id 
    from parents; 
$$ language sql stable strict rows 5 cost 1; 

Un autre problème est que vous ne pouvez pas utiliser FOR UPDATE avec CTEs récursif (pour très bien la même raison, en fait).