Massive performance issue querying entities with many relations

Issue Description

I have a query builder I am running to query for items in a table and loading their relations

let deviceQuery = deviceRepo
    .createQueryBuilder('device')
    .leftJoinAndSelect('device.tankType', 'tankType')
    .leftJoinAndSelect('device.customer', 'customer')
    .leftJoinAndSelect('device.organization', 'organization')
    .leftJoinAndSelect('device.location', 'location')
  const devices: Device[] = await deviceQuery.getMany()

This table only has 7 items on it. When executing this query it takes upwards of 2500ms to return. If I replace .getMany() with .getRawMany() the query only takes 140ms. I can also take the generated SQL from typeorm and paste it into PGAdmin and the query will also only take 140ms there. Something is going terribly wrong with the mapping process to the entity.

Expected Behavior

For .getMany() to be performant when querying for entities that have only 4 relations on them.

Actual Behavior

.getMany() is 15x slower than .getRawMany().

Steps to Reproduce

1. Create an entity with 4+ @ManyToOne()/@OneToMany() relations
2. compare .getMany() to .getRawMany()

My Environment

Dependency	Version
Operating System	Windows
Node.js version	v12.18.3
Typescript version	v3.9.7
TypeORM version	v0.2.29

Additional Context

Relevant Database Driver(s)

• aurora-data-api
• aurora-data-api-pg
• better-sqlite3
• cockroachdb
• cordova
• expo
• mongodb
• mysql
• nativescript
• oracle
• postgres
• react-native
• sap
• sqlite
• sqlite-abstract
• sqljs
• sqlserver

Are you willing to resolve this issue by submitting a Pull Request?

• Yes, I have the time, and I know how to start.
• Yes, I have the time, but I don’t know how to start. I would need guidance.
• No, I don’t have the time, although I believe I could do it if I had the time…
• No, I don’t have the time and I wouldn’t even know how to start.

[m4tta]

It was the @RelationIds that caused all the problems. When I would execute a .getMany() it would run about 11 queries. Picking one of these extra queries out and running it in pgadmin I noticed it was just giving me lists of Ids. This was a massive misunderstanding on my part on the cost of @RelationId. Running postgres locally was just so lightning fast it masked the “real” query time. I thought they were free, and added paired it with every relationship I had even if it wasn’t needed at the time.

Thank you so much for leading me to the right conclusion.

I think the loading of RelationIds can be improved though. When digging into all of this it seemed that when running the 11 queries instead of running in parallel they were waiting for the previous to finish. This is evident by the total query time seeming to be the sum of all 11 queries. These queries are not dependent on each other and should be able to be executed at the same time making this take as long as the slowest query.

[nebkat]

Glad you got it figured out. @RelationId is still an experimental feature so hopefully that will be improved, but there should probably be more information about how it works in the background to avoid confusion like this. Generally the ORM hides the fact that one-to-many relations are much more complex than many-to-one. I personally avoid using them except for single item queries.