On Thu, Jun 4, 2009 at 10:34 AM, Doug Judd <[email protected]> wrote: > Yes, the default mode would be 0. I'm assuming we can plumb this flag all > the way up through the Thrift interface, yes?
Sure. > On Thu, Jun 4, 2009 at 10:02 AM, Luke <[email protected]> wrote: >> >> +1 Makes sense, especially for load data infile operations, as fine >> grained error handling is not needed. I assume the default mode is 0, >> i.e., the flag would not be set. >> >> On Thu, Jun 4, 2009 at 9:54 AM, Doug Judd <[email protected]> wrote: >> > To improve bulk load performance, I'd like to make the following changes >> > to >> > TableMutator: >> > >> > 1. Add a 'flags' argument to the TableMutator constructor and support a >> > flag >> > called FLAG_NO_LOG_SYNC. This will put the mutator in a mode where it >> > will >> > instruct the RangeServers to not call sync() after the commit log write. >> > 2. In FLAG_NO_LOG_SYNC mode, the TableMutator::flush() method and the >> > destructor will invoke RangeServer::commit_log_sync() on all of the >> > range >> > servers that received mutations. >> > 3. Augment the LOAD DATA syntax to support a NO_LOG_SYNC clause which >> > will >> > cause the underlying mutator to be opened with the FLAG_NO_LOG_SYNC >> > flag. >> > >> > - Doug >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en -~----------~----~----~----~------~----~------~--~---
