Hi, > In your test case, you didn't actually *execute* the statement. So it was "prepare a statement" versus "do nothing"
I think a more realistic use case is: (a) prepare, bind the values, and execute a simple statement, versus (b) just bind the values and execute it. Regards, Thomas On Mon, Jul 29, 2013 at 11:42 PM, cowwoc <[email protected]> wrote: > 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]> 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 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. > > > -- 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.
