Steve Ebersole ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16441 ( https://hibernate.atlassian.net/browse/HHH-16441?atlOrigin=eyJpIjoiMDEzZT... ) Re: Implement BatchFetchStrategy-like support for @BatchSize ( https://hibernate.atlassian.net/browse/HHH-16441?atlOrigin=eyJpIjoiMDEzZT... ) I just implemented the following strategies: * if hibernate.query.in_clause_parameter_padding is enabled, a modified version of the legacy “coin change algorithm” approach is used - the modification is to use padding within each partition - SingleIdEntityPartitionedBatchLoader * Otherwise, generally, a “static SQL” approach is used where we use a single SQL with batch-size number of parameters, with null padding for “empty slots” - SingleIdEntityPaddedBatchLoader * Also implemented a dynamic approach where we create SQL on the fly each time for the specific number of ids. Christian Beikov ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) also suggested possibly using an array parameter which I also like. I think we should limit the options here a bit though. Does anyone see the benefit of the dynamic approach? To me, “static SQL” and array-parameter would be enough; maybe with a fallback to partitioned if the “static SQL” batch-size exceeds a certain limit? ( https://hibernate.atlassian.net/browse/HHH-16441#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16441#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100221- sha1:78e8bd6 )