3 ms·
in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the d
by dickfickling 5y ago
in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.
- eurasiantiger 5y agoI have a feeling that does not work at all in non-trivial scenarios, e.g. if both composite keys and date range matching are required to resolve a reference.
- sbarre 5y agoCould you test this and get back to us with the results?
- sorenbs 5y agoThere are pretty extensive docs on how Prisma optimises n+1 queries: https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#n1-in-other-contexts https://www.prisma.io/docs/guides/performance-and-optimizati...
- eurasiantiger 5y agoThe examples are still for a trivial case of joining one thing to many things. What about joining one thing to many things that join to many things that join to one thing that joins to many things that join to many things that join to many things?
- Sujan 5y agoNo need to test really - indeed more complicated cases are not covered by this yet. But happy to look at any Github issues with reproduction of cases that are not working, but could or should work to make your life better.
- brap 5y agoVery interesting, thank you. Is there a way for me to monitor what Prisma is doing in my use case?
- dickfickling 5y agousing `new PrismaClient({ log: ["query"] });` it'll log all the actual sql queries it's running, so you'll be able to see if queries are being combined
- brap 5y agoAwesome, thanks! Turns out Prisma wasn’t optimizing my queries, I think it has to do with me not using the sub query API and instead querying tables seperately (e.g posts.findMany({ where: { owner: user } }))
- Sujan 5y agoPleeeeeease open an issue if you have a simple reproduction for this. That will make sure we will make sure this _does_ work (sooner or later, not committing to a timeline here on HN of course :p).
- tehlike 5y agoIf it's optimizing with figuring the calls in a single tick out, one can probably still optimize further by using db specific features, like postgres supports json_agg which let's you not only break n+1 in a way, but also prevents cartesian product explosion with joins
- hnjobaccount 5y agoFor the interested, here's an article that explains how the dataloader manages to pull this off https://www.mikealche.com/software-development/advanced-promises-in-javascript-building-a-simple-dataloader https://www.mikealche.com/software-development/advanced-prom...
- m007850 5y agoThis isn't true. Prisma currently only supports batching of findUnique queries: https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#solving-n1-in-graphql-with-findunique-and-prismas-dataloader https://www.prisma.io/docs/guides/performance-and-optimizati... There's an issue open for findMany as well, but it hasn't moved in over a year: https://github.com/prisma/prisma/issues/1477 https://github.com/prisma/prisma/issues/1477
- Apofis 5y agoIs 933 open issues a warning sign? Seems excessive.