I've moved the batch logic to the relational.rs module, where we can use table information.

I hope I got the math right:

• InsertQuery uses one bind for block_range and one bind for each column in the given table.
• ClampRangeQuery always uses 2 binds: one for block_range and another for the entity ids array. Assuming that one array uses only one bind, I understand we shouldn't batch it.

Yes, I agree on what you say about ClampRangeQuery - the one thing to check is if there is some other limit on array size. IIRC, in other contexts it was actually advantageous to break queries with large arrays into smaller ones because you get O(n^2) behavior from scanning these large arrays, so that, for example 10 queries with an array of length 1000 was faster than 1 query with an array of length 10,000

The docs state that array size limits are ignored, but Postgres will complain if the field size exceeds 1GB.
From what I have (quickly) researched, I couldn't any info on what that optimal array size for inserting values would be.

Do you believe this could be better addressed and reviewed in a new issue/PR?
If so, I can create and assign myself to it.