That's improved things greatly for my test cases, thanks!
On Saturday, December 26, 2015 at 7:35:43 AM UTC-5, Noel Grandin wrote:
>
> I have puhed a fix for this to master. Please try it out and let me
> know how it works for you.
>
> The fix changes the index costing quite a bit, so it might a
I have puhed a fix for this to master. Please try it out and let me
know how it works for you.
The fix changes the index costing quite a bit, so it might affect
other queries too.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe fr
James, I think query optimizer hints would really help here. Unfortunately,
no one has offered to implement them yet, I think.
On Wednesday, 23 December 2015 18:07:00 UTC+1, James Sheets wrote:
>
> Just to be clear, by "covering" I meant an index that covers the predicate
> and the projection.
Just to be clear, by "covering" I meant an index that covers the predicate
and the projection.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubs
Yes, but there's a very large real-world performance difference between
using the index I've created and the unique key that H2 chooses. I don't
know anything about the internals of H2, but I could make some guesses as
to why.
I personally think the most intuitive behavior would be to use a c
On 2015-12-22 05:28 AM, James Sheets wrote:
Try making another unit test, checking that the below query uses 'tbl_b_idx',
and the test case will fail:
EXPLAIN ANALYZE
SELECT MAX(b.id)as id
FROM tbl_b b
GROUP BY b.tbl_a_id;
For this particular query, you need to read all of the rows, so the
Thanks!
I tried out your changes, and it's made some improvement. The query I
originally submitted does seem to use the correct index.
However, if you just slightly modify the test query (which I see you made a
unit test for), the same issue comes back up.
Try making another unit test, checkin
I have committed a fix for this to master. You can either build from
source or try out the nightly build later
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-
I added some debug and this is the output:
2015-12-19 14:36:15 jdbc[3]: Plan : calculate cost for plan [B, A]
2015-12-19 14:36:15 jdbc[3]: Plan : for table filter B
2015-12-19 14:36:15 jdbc[3]: Table : potential plan item cost
509,990 index PUBLIC.TBL_B.tableScan
2015-12-19
This is the output of EXPLAIN ANALYZE for me:
EXPLAIN ANALYZE
SELECT MAX(b.id) as id
FROM tbl_b b
JOIN tbl_a a ON b.tbl_a_id = a.id
GROUP BY b.tbl_a_id
HAVING a.active = true;
PLAN
SELECT
MAX(B.ID) AS ID
FROM PUBLIC.TBL_A A
/* PUBLIC.TBL_A.tableScan */
/* scanCount: 101 */
INNER JOIN
I've got a fairly simple query using a GROUP BY, but the query optimizer
won't pick the index I've created. Instead, it'll use the indexes for the
constraints on the table instead, which is much slower.
I've tested this on 1.4.189 and 1.4.190 with the following JDBC url:
jdbc:h2:c:/temp/databas
11 matches
Mail list logo
