3 ms·
A quick search of the Github issues seems to indicate that PostGraphQL does suffer from the N+1 query problem at least to some extent (https://github.com/calebm
by fabian2k 10y ago
A quick search of the Github issues seems to indicate that PostGraphQL does suffer from the N+1 query problem at least to some extent (https://github.com/calebmer/postgraphql/issues/219 https://github.com/calebmer/postgraphql/issues/219).
Which probably doesn't matter as long as you only have a few nested children, but might seriously kill performance for some cases. I always find it disappointing when that much of the power of a database like Postgres is thrown away by an abstraction. I find the general approach of PostGraphQL (and Postgrest, which is a similar project for a Postgres REST API) very interesting, it would be nice if it also generated reasonable queries for this kind of data.
- sorenbs 10y agoThe issue mentioned in that post - the fact that this query generates 6 sql queries instead of 2 {allPosts(first:5){title}} is a limitation of the implementation and not inherent to the architecture. We spent a lot of time optimising these cases for graph.cool and the result is that we actually have a more scalable system by issuing a few simple sql queries instead of one giant join. It does open the door for the result to be internally inconsistent, but that is no different from querying a bunch of cached rest endpoints.
- ruslan_talpa 10y agoYou are doing the job of the database query planner. A good join (using indexes) will always beat your 3 simple sequential queries. This mindset i think is due to mysql 4.x which sucked at joins.
- ruslan_talpa 10y agoPostgREST generates ONE query no matter what fields or how many levels you request, so it does use all the power provided by PostgreSQL