Ivan, Nikolay, guys
Sorry if I didn’t put it very clearly. The only caveat I would like to
emphasize is that we must invalidate the results. H2 does this by comparing
table's maxDataModificationId with the databases' current modificationDataId.
We have a H2StatementCache, where Query object
Hello, Konstantin.
> I think we cannot just turn this optimization on
Why is that?
If we turn on `OPTIMIZE_REUSE_RESULT` consequences would be the following:
* concurrent updated of the subquery table will not be used(we have no
guarantee on that, for now)
* performance of the select increase
Thank you for your response, Konstantin
I think we cannot just turn this optimization
>
Of course not, that is the reason why I started this thread.
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table don't change
> it neither on remove or update
Yes, but we can increment this
Hello, Ivan
I think we cannot just turn this optimization on because a result invalidation
counts on org.h2.engine.Database#modificationDataId (see
org.h2.command.dml.Query#sameResultAsLast(Session, Value[], Value[], long)),
but org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
Hello folks.
Recently I trying to investigate why when the query, i.e. «SELECT * FROM T1
WHERE ID IN (SELECT T1_ID FROM T2), is executed locally,
subquery evaluated, even if result is the same. I noticed, that in mentioned in
subj (.ConnectionManager#DEFAULT_DB_OPTIONS),
parameter
