Right! Thanks Evgenij, I will change that immediately.
Thanks again guys.
On Friday, 30 September 2022 at 12:57:50 UTC+2 Evgenij Ryazanov wrote:
> Hello!
>
> You need to pass true as the last argument (approximate). It allows to
> return a fast approximation instead of exact number of rows in
Hello!
You need to pass true as the last argument (approximate). It allows to
return a fast approximation instead of exact number of rows in the index.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop
BTW: there are usually about 30 tables. Some approaching 100K rows, the big
one being the only that goes into the millions.
On Friday, 30 September 2022 at 12:52:49 UTC+2 Silvio wrote:
> Thanks Noel,
>
> Also see my other remark. I will look into that table. Actually, we did
> some stuff
Thanks Noel,
Also see my other remark. I will look into that table. Actually, we did
some stuff directly on the INFORMATION_SCHEMA tables before but the H2
versions above 200 had some modified layout/content in there so we switched
to the JDBC call for this one.
On Friday, 30 September 2022
I read up on the method and now realize the call returns a number of
statistics (like CARDINALITY) that is based on the rows in the index. That
explains the slowness. The problem is that I only need to know which
indexes there are on each table and do not care about the statistics.
The tables
How many tables do you have, that should return in milliseconds.
You could try rinning the built in profiler (see the docs) and see what it
is doing.
You could also directly query the metadata table INFORMATION_SCHEMA.INDEXES
--
You received this message because you are subscribed to the
I have a largisch database (~6G) which I use in H2 2.1.214 embedded mode on
an NVME SSD. I use the JDBC call
rsIdx = con.getMetaData.getIndexInfo(catalog,schema,table,false,false)
to get the indexes for a single table (which is by far the largest in the
whole database) that contains about 3.6
