3 ms·
The SQL your graphql implementation’s ORM middleware generates won’t optimize as well as hand-written SQL in many cases. A decent system will provide the hooks
by jmull 6y ago
The SQL your graphql implementation’s ORM middleware generates won’t optimize as well as hand-written SQL in many cases.
A decent system will provide the hooks you need to hand optimize certain cases somehow, but There are always limitations and hoops to jump through and additional complexity to manage. The extra layers that are meant to make your life easier are getting in the way instead. (May or may not still be worth it, but the point is, it’s not a foregone conclusion.)
- goto11 6y agoBut why wont it optimize as well as hand-written SQL? How can the query optimizer even tell the difference? Surely the SQL is transformed into some kind of syntax-independent abstract query tree before it is passed to the optimizer.
- mixedCase 6y agoNo such thing. The database interface is SQL. The query optimizer is something run in the database.
- goto11 6y agoYes I mean inside the database engine. The engine receives SQL and parses it and then pass the query tree to the optimizer which generate a query plan. My question is how the optimizer could have problems if the SQL is generated as opposed to hand-written? How could that make a difference?
- jmull 6y agoThere are a lot of ways to write a SQL query against a set of tables, given a set of input parameters, to get the desired result. (Not just syntactic or other superficial differences, but differences in logic and how relationships are specified.) And, of course, an optimizer will handle different SQL queries differently.