The number of updated rows that the Change Selector captures and processes for replication between commit points in the originating user transaction.
After capturing the updated rows, the Change Selector issues an SQL Commit consisting of its writing the captured data to the metabase queues. This activity releases the locks on those queue tables, then continues processing the user transaction.
The Change Selector always commits when the user's transaction completes and the queue tables are completely updated; the Change Selector does not change the commit points of a user's transaction.
If you specify 0, the intermittent commits feature is turned off before the end of the user transaction. This results in only one commit being issued when the end of the user's transaction is encountered.
Note: SQL commits can be time consuming if done frequently. To improve throughput you can reduce, if possible, the number of SQL commits. However, this would probably only make a difference if the user transactions are on average, “large”. Therefore you can either turn off, or set commit_freq to a larger value than the default.
Default: 10
Name in the configuration file: commit_freq