The performance difference used to be extremely significant due to the overhead of the MyBatis stores. But with the recent changes to drop MyBatis the difference should be pretty negligible - just some added overhead for writing extra transactions to storage.
The corner cases are just that startJobUpdate only supports services. So for adhoc jobs you'll still need to use createJob. On Wed, Nov 22, 2017 at 4:28 PM, Renan DelValle <renanidelva...@gmail.com> wrote: > HI all, > > I'm working to introduce a change into our thrift client to use the > StartJobUpdate thrift call instead of JobCreate to launch jobs on Aurora > because JobUpdate has some functionality that is desirable over a JobCreate > (i.e.: rolling back on a failure, group sizing, wait for batch completion, > etc.). > > I was wondering if anyone knew what the performance impact might be, if > any, of using the StartJobUpdate thrift call over the JobCreate thrift > call. > > Going further, are there any gotchas or corner cases where this approach > might not make sense? > > Any insights are greatly appreciated. > > -Renan >
