Adding more tables increases the number of generated TableNotEqual trait impls by N squared, since the allow_tables_to_appear_in_same_query macro generates pairwise trait impls. Past about 10-15 tables this N squared codegen has a significant impact on compile time.

Making this more difficult, there's no way to prevent the autogenerated allow_tables_to_appear_in_same_query block except via patch file. We already have an existing patch file to deal with another schema issue, and it doesn't look like there is a way to specify multiple files in diesel.toml.

I'm not sure how to fix this, aside from completely reworking how table checks work. I recognize it's important as part of the type system to not generate queries spanning two disjoint databases, but this is a problem many if not most users won't encounter. Perhaps there's a more scalable way to do the same check with an O(1) trait generation like BelongsToDatabase<T> and some clever bounds checking.

Setup

Versions

• Rust: 1.82.0
• Diesel: 2.2.3
• Database: Postgres
• Operating System: Ubuntu 22 LTS

Problem Description

We started noticing this more as we've added more tables, and it got significantly worse after changes to the coherence checker in Rust 1.82.

Compounds with rust-lang/rust#132064

Steps to reproduce

Create a database with a large number of tables, via diesel cli and the normal migrations. In our case we have about 70 tables in our database. The

Generate a library crate with associated autogenerated schema.rs, import it and time the build.

Nightly isn't required to exhibit the problem, but RUSTFLAGS=-Ztime-passes cargo +nightly check shows the majority of time being spent in the coherence checker. This is consistent with a very large number of trait impls (by my estimate, 70 tables with the Postgres backend will generate approximately 50000 trait impls!)

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate