A volatile table is defined as a table whose contents can vary from empty to very large at run time. In other words , statistics data is often out of date and may result in wrong access plans by the optimizer and subsequently may have lock the entire table than the particular row in certain cases even we implemented row level locking on such tables.
Why is it useful?
|Who would benefit from this IDEA?||All of the customers with such access pattern and finally the whole informix DB server use community|
How should it work?
The proposed solution would be to use better query access plans by the optimizer and avoid such unforeseen table access locking issues. This issue is a common issue in most of our bigger customer sites with high transactional work activity when accessing highly volatile table data. Current workaround would be: , To add dummy records and keep as it is (without getting empty during transactions) to trat this as a normal table or run update statistics when we have a considerable number of records and keep this inconsistent statistics without clearing on such tables. However, this would be a painful process as we need to consideror treat each individual tables seperately. If we have proper solution, It is clear we would get most of the benifits to support and run customer's business operations to run smoothly without our interference.
|Priority Justification||As there are more than 1000 of customer sites, it would be hard and time consuming process to treat such volatile table in a manual way.|
|Customer Name||Pronto Software Ltd|
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions