On 29/07/2013 4:53 PM, Thomas Mueller wrote:
Hi,
In your test case, you didn't actually *execute* the statement. So it
was "prepare a statement" versus "do nothing". Well, if the difference
in time is so small, then I guess it doesn't make much sense to
support this feature.
That was by design. I thought we were trying to measure the
difference between preparing a statement once per transaction (as I was
proposing) versus preparing it once per trigger fire(). Was that not the
case?
So, instead of continuing to discuss this back and forth, let's just
keep the current trigger interface as it is, and whenever we do *have*
to change it, then let's keep this discussion in mind. Specially,
instead of passing 6 parameters, pass an object that contains that
data (Metadata in your case). This was done in other places already:
CreateTableData.
Okay.
Gili
Regards,
Thomas
On Sat, Jul 20, 2013 at 8:37 PM, cowwoc <[email protected]
<mailto:[email protected]>> wrote:
Hi Thomas,
On 20/07/2013 1:10 PM, Thomas Mueller wrote:
Hi,
> but that can lead to deadlocks ...
>e.g. see this previous discussion:
As part of that discussion, I wrote: "I suggest to use
PreparedStatement, and always create a new PreparedStatement (for
each invokation of the trigger). Internally, the database caches
a low-level part of a PreparedStatement,..."
So, I wonder if caching prepared statements is really a problem?
I wrote a quick benchmark against an in-memory database that
inserts a million rows, then drops them. I ran this against a
trigger that creates a new PreparedStatement in fire() and with a
trigger that creates a new PreparedStatement in init().
Multiple PreparedStatement: 1.746 seconds
One PreparedStatement : 1.427 seconds
So we're talking about an overhead of 0.319 ms per invocation.
Please double check the attached benchmark to make sure I'm not
doing anything wrong.
> I am under the impression that it doesn't matter whether a
Trigger's resources get cleaned up due to the Trigger being
dropped or the database being closed. Do you have a use-case that
counters that?
The use case is: you might want to drop a table when the trigger
is removed, but do nothing if the database is closed.
Fair enough, so let's keep them separate.
Thanks,
Gili
--
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 [email protected]
<mailto:h2-database%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "H2 Database" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/h2-database/Sb3T1aVwoCE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
