Pad to the nearest power of 2. The performance improvement comes from the
likelihood of reusing the SQL Execution Plan on DBs that have a cache for
that: Oracle, SQL Server, DB2.
Vlad
On Sun, 12 Aug 2018, 04:43 Steve Ebersole, wrote:
> Pad to what? The number of elements in that passed list ca
I added support for IN query clause parameter padding:
https://vladmihalcea.com/improve-statement-caching-efficiency-in-clause-parameter-padding/
So, we also support this feature since Hibernate 5.2.18 and 5.3.
Vlad
On Fri, Aug 10, 2018 at 5:34 PM, Steve Ebersole wrote:
> Unless someone added
Unless someone added support for it recently, the padding for IN is not for
Query handling, it's for batch loading which is a very different scenario.
With batch loading we know a finite number of JDBC params - the batch size.
On Fri, Aug 10, 2018, 9:17 AM Vlad Mihalcea wrote:
> We already have
Pad to what? The number of elements in that passed list can literally be
anything between 1 and Interger#MAX_VALUE. Are you saying that we should
expand any/all multi-valued parameters to Interger#MAX_VALUE JDBC params?
I guess we could do "buckets" of padding, but I am not convinced that
really
If we can avoid keeping the AST, that would have my preference too.
In 5.x, the AST contains elements that are collected while parsing and then
kept there. We are then forced to keep the AST around. They should be
pushed in a specific container so that we can keep only the strictly
necessary infor
We already have the parameter padding for IN queries, and there's a PR for
supplying ARRAY via ANY(?).
For the second approach, we just have to test it thoroughly to make sure
that all major JDBC Driver support it properly.
Also, I'd only have the second approach activated via a config property as
I'd like to note that with the array rendering strategy i.e. `where x =
ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
necessary to keep the SQL-AST around for the purpose of parameter
expansion, but
In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
(polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
AggregatedSelectQueryPlanImpl
hold 2+ ConcreteSqmSelectQueryPlans. AggregatedSelectQueryPlan operates
much like
Hi,
>From what I can see, the HQLQueryPlan objects are rather big, mostly due to
the sqlAst element of the QueryTranslators.
They can consume a fair amount of memory when you have a lot of HQL queries.
We need at least some of the information collected by the AST but I'm
wondering if we really n
