Gavin King

> The thing is, in case you don't need all the result rows, you are over-allocating memory and over-fetching rows. Well, no, that's not right. 1. JPA fully-instantiates the a...

> feedback welcome >> When you read rows from a ResultSet, under the hood JDBC will fetch 10 rows at a time AFAICT, this is only true for Oracle, FTR....

Look, if were so important to futz about directly with the fetch size for every query, there's no way that JPA would have made it through 20 years of existence...

> We had a case of a broken query which caused an out of memory error because of the `q.list()` call, and we didn't get to see the hibernate exception...

Look, honestly, it really looks to me like you're overthinking this. People get into trouble when they think they can do something better/different to what has already been working perfectly...

Yep, exactly. (None of that means we shouldn't provide a `Query.setFetchSize()` method in JPA; I'm only saying why it's rarely used.)

> Note that DB2 jdbc driver seems to have a default fetch size of 32. How did you determine this? On Db2 LUW, `Statement.getFetchSize()`, `PreparedStatement.getFetchSize()`, and `ResultSet.getFetchSize()` all return `0`...

> I found 32 here: I mean, these are just some blogs from > 10 years ago. People post wrong information on blogs all the time. > db2 on mainframe...

> Maybe it is a good idea to collect very common options like fetchsize, batchsize, batchtype (IN, JOIN, Subquery, EXISTS etc.), cache size etc. and make them a part of...

Looks reasonable, but is a similar change needed in `EntityType.isEqual()`?