Hi,
I'm sorry, but I'm not familiar with JBoss. I know that the 2-phase-commit
implementation of H2 is currently incomplete, and probably this is the root
cause of the problem.
What H2 can't do currently is: after a crash, in the recovery phase, H2
doesn't allow to start a new transaction until
Hi,
Yes, that's weird. I found the problem now. The test case:
create table test(a int, b int);
select t.a, t.b t.c from test t;
The parser thinks the statement finishes at
select t.a, t.b t
and then doesn't find the column. I will try to fix the parser.
Thanks for reporting!
Hi,
If course you could change the CSV source code; it is so small that
rolling your own might not be a problem even in the long run.
H2 has decided that a particular representation of the zero-length string
always means NULL.
Yes, so far. Even thought there is a relatively simple and clear
I'll tune in here to provide you with some background info from the jOOQ
side. When Markus used jOOQ to *inline* bind values (e.g. WHERE
foldermap.parent IN (1, 2, 3, 4)), the query ran in an acceptable time on
my machine - around 1/2s. In the latter query, jOOQ renders bind values as
question
Hi Lukas,
you are right. Now I did four tests.
First with inline (e.g. where foldermap.parent in (1,2,3,4,...)) - the
query takes less than 2 seconds to finish.
Second with indexed parameters (e.g. where foldermap.parent in
(?,?,?,?,...)) - the query takes arount 37 seconds to finish.
Third
Hi
Thanks for the updated test case.
I've looked into this, and the situation is thusly:
We have special case optimised code for handling IN (1,2,3) queries.
Unfortunately, for IN (?,?,?) queries the optimised code does not get
used because we at the point in time we run the optimiser, the
Hello,
2013/10/8 Noel Grandin noelgran...@gmail.com
Hi
Thanks for the updated test case.
I've looked into this, and the situation is thusly:
We have special case optimised code for handling IN (1,2,3) queries.
Unfortunately, for IN (?,?,?) queries the optimised code does not get
used
On 2013-10-08 11:42, Lukas Eder wrote:
In SQL, some expressions are deterministic (in the Oracle sense of
the word), and some expressions are constant. Both expression
attributes propagate through expressions. If a function F is
deterministic, then F(A, B) is deterministic only if both A
Hi,
I'm really impressed by the your support. Thank you for this.
@Noel: If it's to hard to implement then don't think to long about it. As
you said it's a special case (although I like it to use the jOOQ Function
`select * from something where x in (Collection of Ids)', but it's not to
hard
Thanks! That works fine.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to
Thomas,
Took a look at the source and it is pretty straightforward. Changed/added
four or five lines and it seems to be working fine.
Understand why you don't want to change the behaviour since it would almost
certainly break existing stuff and as you say add complication to an
already messy
Hi,
I think the documentation is quite clear.
Of course in Java, you can pass around objects to any thread you like. If
your application has a handle on an object, you can also call methods on it
concurrently in multiple threads. H2 is thread-safe (as documented), but
there are parts of the JDBC
Hi,
So, if accu is less than 100%, the rest of the time went where?
To other queries or statements that are below that line.
And if self is less than accu in hprof it has to do with sub-function
execution time, I believe
No. Self mean self, I don't know how to explain it otherwise sorry.
Hi,
Would it be possible to disable generating CAST? If the bind variable is
set using PreparedStatement.setLong, I don't see why CAST would be needed.
Of course support for superfluous CAST (or any deterministic function on a
parameter) could be implemented in H2, but so far it wasn't needed,
2013/10/8 Thomas Mueller thomas.tom.muel...@gmail.com
Hi,
Would it be possible to disable generating CAST? If the bind variable is
set using PreparedStatement.setLong, I don't see why CAST would be needed.
This is why:
Hi,
I see. Maybe it would make sense to add a special case for CAST(? AS
type) in the parser, so that it's still a parameter, but with a specific
type. I will try.
Regards,
Thomas
On Tue, Oct 8, 2013 at 7:39 PM, Lukas Eder lukas.e...@gmail.com wrote:
2013/10/8 Thomas Mueller
Oh. accu is just a running sum?
On Tuesday, October 8, 2013 10:24:11 AM UTC-7, Thomas Mueller wrote:
Hi,
So, if accu is less than 100%, the rest of the time went where?
To other queries or statements that are below that line.
And if self is less than accu in hprof it has to do with
I believe this can also be caused by the OS block caching, which won't be
affected by restarting H2. I see this behavior:
1) Run query in embedded app, it takes 15 sec
2) Shut down and run the same query in console, it takes 200 ms
3) Run it in the app again after restarting, it takes 200ms
4)
I'm wondering if these numbers look typical of h2, or if I still have some
bottleneck I haven't identified.
I have a probes table (mentioned in other threads) with one index over two
columns: eid (int) and name (varchar). (eid, name) is unique. For each eid
there might be 10k-500k rows.
The
Hi
Yes, in percent.
Regards,
Thomas
Am 08.10.2013 21:01 schrieb Brian Craft craft.br...@gmail.com:
Oh. accu is just a running sum?
On Tuesday, October 8, 2013 10:24:11 AM UTC-7, Thomas Mueller wrote:
Hi,
So, if accu is less than 100%, the rest of the time went where?
To other queries
Hi,
According to a simple test case, H2 is already using an index when using an
unnecessary CAST. So I'm not sure yet what the problem is for your case.
Could you run the query with explain and post the query plan? Example:
Connection conn = DriverManager.getConnection(jdbc:h2:mem:);
Statement
21 matches
Mail list logo
