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.
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. Regards, Thomas On Sat, Jul 20, 2013 at 8:37 PM, cowwoc <[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]. > 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.
