Orden de unión de tabla en postgres

Question

¿Hay alguna manera de forzar una orden de unión específica en Postgres?

Tengo una consulta que se parece a esto. Eliminé un montón de cosas que estaban en la consulta real, pero esta simplificación demuestra el problema. Lo que queda no debe ser demasiado críptico: al usar un sistema de seguridad de roles/tareas, estoy tratando de determinar si un usuario dado tiene privilegios para realizar una tarea determinada.

select task.taskid 
from userlogin 
join userrole using (userloginid) 
join roletask using (roleid) 
join task using (taskid) 
where loginname='foobar' 
and taskfunction='plugh' 

pero me di cuenta que el programa ya conoce el valor de userlogin, por lo que parecía la consulta podría ser más eficiente por saltarse la búsqueda en userlogin y simplemente rellenando el userloginid, así:

select task.taskid 
from userrole 
join roletask using (roleid) 
join task using (taskid) 
where userloginid=42 
and taskfunction='plugh' 

Cuando lo hice, eliminando una tabla de la consulta y codificando el valor recuperado de esa tabla en su lugar, ¡el tiempo del plan de explicación se incrementó! En la consulta original, Postgres leyó userlogin luego userrole luego roletask then task. Pero en la nueva consulta, decidió leer roletask primero y luego unirse a userrole, aunque esto requería hacer un escaneo de archivo completo en roletask.

completa explicar los planes son:

Versión 1:

Hash Join (cost=12.79..140.82 rows=1 width=8) 
    Hash Cond: (roletask.taskid = task.taskid) 
    -> Nested Loop (cost=4.51..129.73 rows=748 width=8) 
     -> Nested Loop (cost=4.51..101.09 rows=12 width=8) 
       -> Index Scan using idx_userlogin_loginname on userlogin (cost=0.00..8.27 rows=1 width=8) 
        Index Cond: ((loginname)::text = 'foobar'::text) 
       -> Bitmap Heap Scan on userrole (cost=4.51..92.41 rows=33 width=16) 
        Recheck Cond: (userrole.userloginid = userlogin.userloginid) 
        -> Bitmap Index Scan on idx_userrole_login (cost=0.00..4.50 rows=33 width=0) 
          Index Cond: (userrole.userloginid = userlogin.userloginid) 
     -> Index Scan using idx_roletask_role on roletask (cost=0.00..1.50 rows=71 width=16) 
       Index Cond: (roletask.roleid = userrole.roleid) 
    -> Hash (cost=8.27..8.27 rows=1 width=8) 
     -> Index Scan using idx_task_taskfunction on task (cost=0.00..8.27 rows=1 width=8) 
       Index Cond: ((taskfunction)::text = 'plugh'::text) 

Versión 2:

Hash Join (cost=96.58..192.82 rows=4 width=8) 
    Hash Cond: (roletask.roleid = userrole.roleid) 
    -> Hash Join (cost=8.28..104.10 rows=9 width=16) 
     Hash Cond: (roletask.taskid = task.taskid) 
     -> Seq Scan on roletask (cost=0.00..78.35 rows=4635 width=16) 
     -> Hash (cost=8.27..8.27 rows=1 width=8) 
       -> Index Scan using idx_task_taskfunction on task (cost=0.00..8.27 rows=1 width=8) 
        Index Cond: ((taskfunction)::text = 'plugh'::text) 
    -> Hash (cost=87.92..87.92 rows=31 width=8) 
     -> Bitmap Heap Scan on userrole (cost=4.49..87.92 rows=31 width=8) 
       Recheck Cond: (userloginid = 42) 
       -> Bitmap Index Scan on idx_userrole_login (cost=0.00..4.49 rows=31 width=0) 
        Index Cond: (userloginid = 42) 

(Sí, ya sé que en ambos casos los costos son bajos y la diferencia doesn Parece que no importaría, pero esto es después de que eliminé un montón de trabajo adicional de la consulta para simplificar lo que tengo que publicar. La consulta real aún no es escandalosa, pero estoy más interesado en t . El principio)

Answer 1

Esta página en la documentación describe cómo evitar que el optimizador PostgreSQL desde la reordenación de las tablas combinadas, lo que le permite controlar el orden de combinaciones mismo:

http://www.postgresql.org/docs/current/interactive/explicit-joins.html

Answer 2

¿Estás seguro de que sus estadísticas de la tabla están actualizados? Cuando el optimizador basado en el costo de PostgreSQL falla con cosas tan triviales, es una buena señal de que algo está muy mal con las estadísticas de la tabla. Es mejor solucionar la causa raíz que solucionar el problema anulando el optimizador incorporado porque el problema aparecerá inevitablemente en otro lugar también.

Ejecute ANALYZE en las tablas afectadas y vea si hace que PostgreSQL seleccione un plan diferente. Si aún elige algo tonto, sería muy interesante ver los planes de consulta. El optimizador que no está haciendo lo correcto generalmente se considera un error.