segundo - Optimizando la consulta SQL generada por Slick

sql server query to html table

Question

Tengo una consulta muy simple que en SQL se puede representar de la siguiente manera:

SELECT
c.id,
count(cp.product_id)
FROM cart c LEFT OUTER JOIN cart_product cp ON c.id = cp.cart_id
WHERE c.id = 3
GROUP BY c.id;

Me sorprendió mucho al usar Slick DSL para representar la consulta anterior, la consulta generada desde el siguiente DSL :

Cart.joinLeft(CartProduct)
.on { case (c, cp) => c.id === cp.cartId }
.filter { case (c, cp) => c.id === 3 }
.groupBy { case (c, cp) => c.id }
.map { case (c, pr) => (c, pr.length)
}

Se ve como sigue:

SELECT
x2.x3,
count(1)
FROM (SELECT
x4.x5 AS x3,
x4.x6 AS x7,
x8.x9 AS x10,
x8.x11 AS x12,
x8.x13 AS x14,
x8.x15 AS x16
FROM (SELECT
x17."id" AS x5,
x17."user_id" AS x6
FROM "cart" x17) x4 LEFT OUTER JOIN (SELECT
1 AS x9,
x18."id" AS x11,
x18."cart_id" AS x13,
x18."product_id" AS x15
FROM "cart_product" x18) x8 ON x4.x5 = x8.x13) x2
WHERE x2.x3 = 3
GROUP BY x2.x3;

¿Qué estoy haciendo mal? ¿Es normal ver tales consultas anidadas? ¿Cuál es el punto de usar Slick DSL si la complejidad de la consulta crece tan rápidamente? Probablemente podría escribir SQL nativo sin embargo realmente me gustó Slick DSL . ¿Cuáles son las técnicas de optimización de consultas Slick ?

Answer 1

Ya que ha escrito que está usando PostgreSQL, entonces no me preocuparía, ya que PostgreSQL es conocido por un optimizador de consultas realmente bueno. Una transformación tan simple no requiere esfuerzo, prácticamente no requiere tiempo adicional. Lo único es que espere, el problema eventualmente se solucionará en sentido ascendente (en algún lugar de la versión 3.1 de Slick) y no tiene que hacer nada.

ps: ¿Por qué no estás simplemente usando esta consulta? Debería devolver exactamente el mismo resultado, si tiene una restricción externa en las tablas:

SELECT id, COUNT(*) FROM cart_product WHERE id=3