Performance of query with many `relations`
**Issue type:** [X] question [ ] bug report [ ] feature request [ ] documentation issue **Database system/driver:** [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [X] `postgres` [ ] `cockroachdb` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` [ ] `expo` **TypeORM version:** [X] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) **Steps to reproduce or a small repository showing the problem:** So I'm having performance trouble with a query that fetches a lot of relations: ``` const user = await User.findOne(id, { relations: [ 'address', 'shippingAddress', 'practice', 'allergies', 'vaccines', 'problems', 'relationships', 'relationships.user1', // returns another User 'relationships.user2', // returns another User ] }); ``` This query takes nearly 2 seconds to run in my Postgres DB (Google Cloud). Here is some additional info: - I'm not factoring in round-trip latency. This is the actual runtime of the query in the db. - All of these are OneToOne or OneToMany relations. - The User entity has a lot of scalar values (40). - The generated query is [really long](https://gist.github.com/colinmcd94/3c5c46e6934720a5f4dae16d01dbe6da) - I've added an index on every OneToOne and ManyToOne relation (`Book.user`, etc) - I would expect this query to take a while if there was a lot of data in the database, but it's nearly empty. I'm still early in development and there are only a f
Posted by colinhacks on Mar 20, 2019, 4:49 PM
Tags
Related issues
- [UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)
- Server requests and latency increased after upgrading from Next.js 15 to 16
- Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
- Can't download videos from YouTube on cobalt.tools
- `google_service_networking_connection` produce an error when trying to destroy the resource
- WebGPU-based renderer for the editor
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Network)
[UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)
Server requests and latency increased after upgrading from Next.js 15 to 16
Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
Can't download videos from YouTube on cobalt.tools
`google_service_networking_connection` produce an error when trying to destroy the resource
WebGPU-based renderer for the editor
Zed downloads NodeJS binary and npm packages from Internet without user’s consent
FR: Allow custom domains for Tailscale Funnel
Performance of query with many `relations`
**Issue type:** [X] question [ ] bug report [ ] feature request [ ] documentation issue **Database system/driver:** [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [X] `postgres` [ ] `cockroachdb` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` [ ] `expo` **TypeORM version:** [X] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) **Steps to reproduce or a small repository showing the problem:** So I'm having performance trouble with a query that fetches a lot of relations: ``` const user = await User.findOne(id, { relations: [ 'address', 'shippingAddress', 'practice', 'allergies', 'vaccines', 'problems', 'relationships', 'relationships.user1', // returns another User 'relationships.user2', // returns another User ] }); ``` This query takes nearly 2 seconds to run in my Postgres DB (Google Cloud). Here is some additional info: - I'm not factoring in round-trip latency. This is the actual runtime of the query in the db. - All of these are OneToOne or OneToMany relations. - The User entity has a lot of scalar values (40). - The generated query is [really long](https://gist.github.com/colinmcd94/3c5c46e6934720a5f4dae16d01dbe6da) - I've added an index on every OneToOne and ManyToOne relation (`Book.user`, etc) - I would expect this query to take a while if there was a lot of data in the database, but it's nearly empty. I'm still early in development and there are only a f
Comments (0)
No comments yet. Start the discussion.