Performance fix for related select

[pimeys]

If the relation column is in the same table, do not join with itself.

We can only do this if the query has no pagination, in the optimal case we can cut a big slice of the response time off.

Query:

query {
  findManyUser(where: { firstName: "Face" })
  {
    firstName
    lastName
    posts { id }
  }
}

Schema:

model User {
  id         Int       @id @unique
  firstName  String
  lastName   String
  age        Int?
  email      String?
  password   String?
  posts      Post[]
  comments   Comment[]
  likes      Like[]
  friendWith User[]    @relation("FriendShip")
  friendOf   User[]    @relation("FriendShip")
  createdAt  DateTime  @default(now())
  updatedAt  DateTime  @updatedAt
}

model Post {
  id        Int       @id @unique
  content   String?
  author    User
  comments  Comment[]
  likes     Like[]
  createdAt DateTime  @default(now())
  updatedAt DateTime  @updatedAt

  @@index([author])
}

model Comment {
  id        Int       @id @unique
  content   String?
  author    User
  post      Post
  likes     Like[]
  createdAt DateTime  @default(now())
  updatedAt DateTime  @updatedAt

  @@index([author])
  @@index([post])
}

model Like {
  id        Int       @id @unique
  user      User
  post      Post
  comment   Comment
  createdAt DateTime  @default(now())
  updatedAt DateTime  @updatedAt

  @@index([user])
  @@index([post])
  @@index([comment])
}

Data generated to psql 10 with sql-load-test with 3 000 000 users, 30 000 000 posts, 30 000 000 comments and 150 000 000 likes.

Green: master, purple: this PR, database psql, y-axis nanoseconds, x-axis requests per second:

Fixes #127

[do4gr]

Not sure if I am missing something, but If I understand correctly you are trying to fix the case where we join even though only the id of the related node is requested AND this Id is inlined in the node above it in the query. For these cases we can get rid of the join and just return the inlined id.

But on your data model the Id is inlined on Post and the fix should not affect that query since we still need to join in order to get the id.

A query that should be affected would be this:

query {
  findManyPosts(where: { content: "Something" })
  {
    content
    author { id }
  }
}

Here the author Id is already contained in Post and we can skip the join.

Can you verify with the logging Postgres Docker image which SQL statements are produced before and after the change for the queries?

[do4gr]

There are also failures on CI with invalid SQL statements, I can look into these tomorrow, or we can do it together.

[pimeys]

This will fix the selection of post id, that is triggered in the end of the query. Master joins post by post due to the author id being in the same table. We don't need to join.

[do4gr]

Ah, ok then we are talking about different cases I think. I was talking about the join from Post to User in my query being unnecessary.
Then I'll need to understand where the Post-Post join was coming from to begin with. I'll check that tomorrow.

[pimeys]

Already fixed on my machine. Didn't push because needed to run.

[pimeys]

And now green tests.

[do4gr]

Looks good to me.