Skip to Main Content
IBM Data and AI Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Data & AI Roadmaps (http://ibm.biz/Data-and-AI-Roadmaps) - Use this site to view roadmaps for Data & AI products.

IBM Employees should enter Ideas at https://hybridcloudunit-internal.ideas.aha.io/


Status Future consideration
Workspace Informix
Components Informix Server
Created by Guest
Created on Feb 17, 2014

Allow "group commit" as other RDBMS

For high use OLTP systems, there can be a lot of I/O pressure on the logical log due to intense rate of logical log buffer flushing (most customer don't ant data loss so they use UNBUFFERED LOG).

Setting BUFFERED LOG at session level would hardly avoid this (on a system with many sessions at least) due to the high probability of lot's of almost simultaneous COMMITS. And it would mean potential "data loss"

Other RDBMS (DB2, Oracle, MySQL) have "solved" this by delaying the write until:
1- A certain number of COMMITS happens or
2- A certain amount of type has elapsed

The application can be forced to wait until the COMMIT is effectively flushed to disk to avoid the potential of data loss.
Currently in BUFFERED LOG we can delay the write, but because the application immediately receives the COMMIT feedback we cannot guarantee zero "data loss".

Currently in most customers with high rate of transactions we can see that we write on average just one page per logical log flush, meaning we're wasting the potential of performance improvement that the log buffer is supposed to give us. As such we have a potential bottleneck.

I suppose this would imply something like:

- new syntax for BUFERED LOG [MAXWAIT n]
where n would be number of ms with a minimum and maximum interval and possibly accepting only X increments
- new syntax for CREATE DATABASE ... WITH LOG [MAXWAIT n]
- Have some sort of list of "pending commits"
- Have a thread or mechanism that checks at X ms interval for sessions waiting on pending COMMITS and if this happens force the flush
  • Guest
    Jul 4, 2022

    When using the parameter LOGBUF_INTVL, the application has already committed the data (from its perspective) and can continue working. In reality the logical log info for that transaction is in memory and a hard reset of the server/VM will actually cause the data to be lost.

    This RFE is about adding an artificial delay (dynamic user configurable parameter, say default 100ms) to wait before acknowledging the commit. This delay increases the probability that other transactions is join in those 100ms and commit together. This decrease contention and improves the throughput from the engine side. The downside of this approach is that the application will wait at worst 100ms for each commit.

    This implementation will give the benefits of group commit without any impact on HA.

  • Guest
    Jul 15, 2021

    Dear Customer,

    We reviewed this idea and we have the below comments:
    1. Log Buffer interval is for quiet systems and does not solve this request.
    2. Implementing this request requires a review of HA and ER cluster implementations and consequences.

    Thanks,
    Karthik Gopalakrishnan

  • Guest
    Oct 16, 2019

    Already implemented in 12.10.FC13. The new parameter LOGBUF_INTVL implements the interval before a flush on the logical log buffer is forced