New RFE entry needs votes

FOlks: I submitted the following RFE to the IBM RFE Community site. If you have an interest in this feature/enhancement, please add your vote: ------------------------------------------------------------ -------------------------------------------------------------- Notification generated at: 07 Jan 2018, 02:57 PM Eastern Time (ET) ID: 114905 Headline: Need the ability to increase the number of logical log buffers from 3 to handle peak transaction loads Submitted on: 07 Jan 2018, 02:57 PM Eastern Time (ET) Brand: Analytics Platform Product: Informix Servers Component: Product functionality Link: http://www.ibm.com/ developerworks/rfe/execute?use_case=viewRfe&CR_ID=114905 ------------------------------------------------------------ -------------------------------------------------------------- Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Art, I have a question about this RFE. Is this a problem that cannot be solved by a larger logical log buffer or are you concerned about having too much data in the buffer not written to disk if you increase the buffer size? Ben.

I suppose the problem is that we rarely use the logical log buffer fully. On a busy system there's constantly some session doing a commit. And that causes the flush of the logical log buffer. This can frequently cause issues due to the saturation of the HDR buffers (12, and not configurable) and eventually in worse scenarios, it may not leave enough time to flush the buffer until it's needed again. I must say I never faced this last situation, but it's common to see the one caused by the HDR buffers. 3 years ago I created another RFE around the same issue: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=45166 The idea here would be to delay the commit response to the application, allowing the buffer to fill a bit more. The idea sounds good, and DB2 does (or used to do) that. I think Oracle also implements something like this. However I've heard informally (couldn't confirm) that this was removed from DB2 because it caused more issues thant the ones it should solve. The tricky part is to delay, "but not too much". The idea is that this should work unnoticeable to the applications doing the commit, but at the same time allow real buffer usage. The main point is that we can never tell the application the data was committed (thus the flush) before it really was. In any case, Art's RFE will get my vote. I have serious doubts about the current RFE process, considering it includes features already implemented in the submitted state and many with many votes that seem to be ignored. But it still should be a good way to express customer requirements to IBM. I have hopes that HCL will improve the process. For the more curious minds and the ones with free time, I digged into this some time ago here: http://informix-technology.blogspot.pt/2014/02/new-feature-nova-funcionalidade.h tml Regards. On Tue, Jan 9, 2018 at 1:04 PM, BENJAMIN THOMPSON < benjamin.thompson@skybettingandgaming.com> wrote: > Art, > > I have a question about this RFE. Is this a problem that cannot be solved > by a > larger logical log buffer or are you concerned about having too much data > in > the buffer not written to disk if you increase the buffer size? > > Ben. > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Intersting, this is generally known as 'group commit'. MySQL has this : http://mysqlha.blogspot.co.uk/2013/09/group-commit-is-good-in-56-and-57.html?vie w=sidebar Postgres has this: https://doxygen.postgresql.org/xlog_8c_source.html I have a vague memory of this being enabled on Online 5. My questions is does adding more logical log buffers avoid the convoy effect where we just fill the additional buffers and then end up stalling anyway? Regards, David. > On 09 January 2018 at 13:24 Fernando Nunes <domusonline@gmail.com> wrote: > > > I suppose the problem is that we rarely use the logical log buffer fully. > On a busy system there's constantly some session doing a commit. And that > causes the flush of the logical log buffer. > This can frequently cause issues due to the saturation of the HDR buffers > (12, and not configurable) and eventually in worse scenarios, it may not > leave enough time to flush the buffer until it's needed again. > I must say I never faced this last situation, but it's common to see the > one caused by the HDR buffers. > > 3 years ago I created another RFE around the same issue: > > http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=45166 > > The idea here would be to delay the commit response to the application, > allowing the buffer to fill a bit more. The idea sounds good, and DB2 does > (or used to do) that. I think Oracle also implements something like this. > However I've heard informally (couldn't confirm) that this was removed from > DB2 because it caused more issues thant the ones it should solve. > The tricky part is to delay, "but not too much". The idea is that this > should work unnoticeable to the applications doing the commit, but at the > same time allow real buffer usage. The main point is that we can never tell > the application the data was committed (thus the flush) before it really > was. > > In any case, Art's RFE will get my vote. I have serious doubts about the > current RFE process, considering it includes features already implemented > in the submitted state and many with many votes that seem to be ignored. > But it still should be a good way to express customer requirements to IBM. > I have hopes that HCL will improve the process. > > For the more curious minds and the ones with free time, I digged into this > some time ago here: > > > http://informix-technology.blogspot.pt/2014/02/new-feature-nova-funcionalidade.h tml > > Regards. > > On Tue, Jan 9, 2018 at 1:04 PM, BENJAMIN THOMPSON < > benjamin.thompson@skybettingandgaming.com> wrote: > > > Art, > > > > I have a question about this RFE. Is this a problem that cannot be solved > > by a > > larger logical log buffer or are you concerned about having too much data > > in > > the buffer not written to disk if you increase the buffer size? > > > > Ben. > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Thanks Fernando, the IBM DW site has been in under maintenance pretty much all day so far. I will take a look at your RFE later.

Ive been doing some thinking about this and would like to make some suggestions. You can take it for what its worth. Its best to make a request for change to describe a problem and not so much a solution. I dont think that just having more log buffers will resolve any problem because the order that any buffer can be reused is dependent on the preceding buffers being reusable. To explain - suppose that you had 10 buffers and commit log records had been placed in all 10. Since the commit log record would have started the log flush of all 10 log buffers, then there would be no free log buffers available for any subsequent log records. This would be identical to the situation that we have today. Also lets suppose that log buffer 5 completed the log flush. Fine, but the threads which were attached to log buffer 5 could still not complete the commit until log buffers 1-4 were complete. Why? Because the transactions issueing the commit in log buffer 5 could have log records in buffers 1-4. If the system were to be restarted before all of the log buffers 1-5 were fully flushed, then you would lose the transaction having the commit log record in buffer 5 and that would break the ACID rules of transactions. Also, if there are a large number of log buffers and there is no control of the IO execution, then all that youve done is to increase the IO contention on the log files, and that would decrease performance. So the solution is probably not so much just increasing the number of log buffers, but rather increasing the number of commits per log buffer while still maintaining good performance and functioning similar to unbuffered logging. Perhaps not allowing the start of IO on buffer 2 until buffer 1 is completely flushed AND allowing additional log records to be placed into buffer 2 until the IO completion of log buffer 1. Yes - those transactions that placed a commit log record into buffer 2 would have to be suspended until the IO completion of the IO on buffer 2 AND the IO would not be initiated until the completion of the IO on log buffer 1. I dont know the solution. I no longer have access to the source code to experiment on a good solution to the problem. But again, Im not sure that the problem is stated in the RFE either. Sent from Yahoo Mail for iPad On Sunday, January 7, 2018, 1:00 PM, Art Kagel <art.kagel@gmail.com> wrote: FOlks: I submitted the following RFE to the IBM RFE Community site. If you have an interest in this feature/enhancement, please add your vote: ------------------------------------------------------------ -------------------------------------------------------------- Notification generated at: 07 Jan 2018, 02:57 PM Eastern Time (ET) ID: 114905 Headline: Need the ability to increase the number of logical log buffers from 3 to handle peak transaction loads Submitted on: 07 Jan 2018, 02:57 PM Eastern Time (ET) Brand: Analytics Platform Product: Informix Servers Component: Product functionality Link: http://www.ibm.com/ developerworks/rfe/execute?use_case=viewRfe&CR_ID=114905 ------------------------------------------------------------ -------------------------------------------------------------- Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

=0AI would agree with my esteemed learned colleague. Increasing the=0Anumb= er of log buffers will not help performance at all. If it would have=0Athis= would be an easy change which would have been done long ago. There=0Aare m= any =0Aissues in dealing with the log buffer and Madison bring up one, but= =0Athere =0Aare several more.=0A=0A=0AJohn=0A=0A-------- Original Message -= -------=0ASubject: Re: New RFE entry needs votes [40481]=0AFrom: "Madison P= ruet" <madison_pruet@yahoo.com>=0ADate: Wed, January 10, 2018 10:09 pm=0ATo= : ids@iiug.org=0A=0AIve been doing some thinking about this and would like = to make some =0Asuggestions. You can take it for what its worth. =0AIts bes= t to make a request for change to describe a problem and not so=0Amuch a = =0Asolution. I dont think that just having more log buffers will resolve=0A= any =0Aproblem because the order that any buffer can be reused is dependent= on=0Athe =0Apreceding buffers being reusable. To explain - suppose that yo= u had 10=0Abuffers =0Aand commit log records had been placed in all 10. Sin= ce the commit log=0Arecord =0Awould have started the log flush of all 10 lo= g buffers, then there would=0Abe no =0Afree log buffers available for any s= ubsequent log records. This would be=0A=0Aidentical to the situation that w= e have today. =0AAlso lets suppose that log buffer 5 completed the log flus= h. Fine, but=0Athe =0Athreads which were attached to log buffer 5 could sti= ll not complete the=0A=0Acommit until log buffers 1-4 were complete. Why? B= ecause the=0Atransactions =0Aissueing the commit in log buffer 5 could have= log records in buffers=0A1-4. If =0Athe system were to be restarted before= all of the log buffers 1-5 were=0Afully =0Aflushed, then you would lose th= e transaction having the commit log=0Arecord in =0Abuffer 5 and that would = break the ACID rules of transactions. =0AAlso, if there are a large number = of log buffers and there is no control=0Aof =0Athe IO execution, then all t= hat youve done is to increase the IO=0Acontention on =0Athe log files, and = that would decrease performance. =0ASo the solution is probably not so much= just increasing the number of=0Alog =0Abuffers, but rather increasing the = number of commits per log buffer=0Awhile =0Astill maintaining good performa= nce and functioning similar to unbuffered=0A=0Alogging. Perhaps not allowin= g the start of IO on buffer 2 until buffer 1=0Ais =0Acompletely flushed AND= allowing additional log records to be placed into=0A=0Abuffer 2 until the = IO completion of log buffer 1. Yes - those=0Atransactions =0Athat placed a = commit log record into buffer 2 would have to be suspended=0Auntil =0Athe I= O completion of the IO on buffer 2 AND the IO would not be=0Ainitiated =0Au= ntil the completion of the IO on log buffer 1. =0AI dont know the solution.= I no longer have access to the source code to =0Aexperiment on a good solu= tion to the problem. But again, Im not sure=0Athat the =0Aproblem is stated= in the RFE either. =0A=0ASent from Yahoo Mail for iPad =0A=0AOn Sunday, Ja= nuary 7, 2018, 1:00 PM, Art Kagel <art.kagel@gmail.com>=0Awrote: =0A=0AFOlk= s: =0A=0AI submitted the following RFE to the IBM RFE Community site. If yo= u have=0Aan =0Ainterest in this feature/enhancement, please add your vote: = =0A=0A------------------------------------------------------------ =0A-----= --------------------------------------------------------- =0ANotification g= enerated at: 07 Jan 2018, 02:57 PM Eastern Time (ET) =0A=0AID: 114905 =0AHe= adline: Need the ability to increase =0Athe number of logical log buffers f= rom 3 to handle peak transaction=0Aloads =0ASubmitted on: 07 Jan 2018, 02:5= 7 PM Eastern Time =0A(ET) =0ABrand: Analytics Platform =0AProduct: Informix= Servers =0AComponent: Product functionality =0A=0ALink: http://www.ibm.com= / =0Adeveloperworks/rfe/execute?use_case=3DviewRfe&CR_ID=3D114905 =0A------= ------------------------------------------------------ =0A-----------------= --------------------------------------------- =0A=0AArt =0A=0AArt S. Kagel,= President and Principal Consultant =0AASK Database Management =0Awww.askdb= mgt.com =0A=0ABlog: http://informix-myview.blogspot.com/ =0A=0ADisclaimer: = Please keep in mind that my own opinions are my own opinions=0A=0Aand do no= t reflect on the IIUG, nor any other organization with which I=0Aam =0Aasso= ciated either explicitly, implicitly, or by inference. Neither do =0Athose = opinions reflect those of other individuals affiliated with any =0Aentity w= ith which I am affiliated nor those of the entities themselves. =0A=0A=0A**= ***************************************************************************= **=0A=0AForum Note: Use "Reply" to post a response in the discussion forum.= =0A=0A=0A*****************************************************************= **************=0A=0A Forum Note: Use "Reply" to post a response in the disc= ussion forum.

Trying to argue with two "monsters" (rest assured this is a compliment) is really a bold move. Please take this as food for thought, and not exactly as an educated opinion: Although the message misses some "newline" changes, and I didn't get the direct reply from Madison, I believe what he's suggesting is that the suggestion I made on the other RFE (group commit) would be a better solution. I was totally convinced about that, but a recent discussion with a person that was somehow involved with DB2 development (and mentioned that group commit caused issues...) raised some doubts. Apart from this, and considering Madison's points are very relevant (and didn't came to my mind innitially) I wonder if just increasing the number of buffers wouldn't help. Taking is example of flushing buffer "5" and how that would require previous flushes of buffers 1-4, we should not forget that it's the current situation we have with buffer "2" and "1", with the (big?) difference that currently we get into this as soon as we trigger a flush on buffer 3. So we only have one buffer before we get into the situation. With the considered scenario we would allow applications to "fill/flush" buffers 6-10 before getting into the issue. I wonder if that wouldn't help.... I do recall an ancient ATLAS case where from the description, a patch was created for an European customer to add more "HDR" buffers. And apparently that helped. It's not the same situation, but I wonder if the effect wouldn't be the same. But I guess that the folks from HCL reading this may consider that.... as long as there is a stress test, it shouldn't be too difficult to try... As to John's statement that "if it was easy, it would have been done before"... That causes me some "issues". I have a list of things that sound "easy" and were never implemented. I have two explanations for this: 1- My concept of "easy" doesn't always match reality. So good feedback like the one provided by Madison helps us, ignorant folks to understand why sometimes things are not that simple. And that feedback should be provided through the RFE system/process 2- Many times there's a huge gap between customer requirements and what's important for them, and the development priorities. This happens for a few reasons: The user's voice is not loud enough (and that's mainly their fault, but there's also a communication channel issue...). Development most of the times is concerned with what big customers want, and with what may gain us a new customer. I'm not criticizing this, but it has its disadvantages. 3- Many times, people that deal with big customers (mainly in the USA) have a privilege access to the development teams and managers, and they sometimes manage to use some "workarounds" that are "good enough". This is an obscure point, and a very personal "complaint" but let me illustrate with an example: What's the use for the common user of the "onstat -g pqs"? However for internal people the information may be very relevant. Regards. On Thu, Jan 11, 2018 at 7:31 AM, John Miller <jmiller@jfmiii.com> wrote: > =0AI would agree with my esteemed learned colleague. Increasing the=0Anumb= > er of log buffers will not help performance at all. If it would > have=0Athis= > would be an easy change which would have been done long ago. There=0Aare m= > any =0Aissues in dealing with the log buffer and Madison bring up one, but= > =0Athere =0Aare several more.=0A=0A=0AJohn=0A=0A-------- Original Message > -= > -------=0ASubject: Re: New RFE entry needs votes [40481]=0AFrom: "Madison > P= > ruet" <madison_pruet@yahoo.com>=0ADate: Wed, January 10, 2018 10:09 > pm=0ATo= > : ids@iiug.org=0A=0AIve been doing some thinking about this and would > like = > to make some =0Asuggestions. You can take it for what its worth. =0AIts > bes= > t to make a request for change to describe a problem and not so=0Amuch a = > =0Asolution. I dont think that just having more log buffers will > resolve=0A= > any =0Aproblem because the order that any buffer can be reused is > dependent= > on=0Athe =0Apreceding buffers being reusable. To explain - suppose that yo= > u had 10=0Abuffers =0Aand commit log records had been placed in all 10. > Sin= > ce the commit log=0Arecord =0Awould have started the log flush of all 10 > lo= > g buffers, then there would=0Abe no =0Afree log buffers available for any > s= > ubsequent log records. This would be=0A=0Aidentical to the situation that > w= > e have today. =0AAlso lets suppose that log buffer 5 completed the log > flus= > h. Fine, but=0Athe =0Athreads which were attached to log buffer 5 could > sti= > ll not complete the=0A=0Acommit until log buffers 1-4 were complete. Why? > B= > ecause the=0Atransactions =0Aissueing the commit in log buffer 5 could > have= > log records in buffers=0A1-4. If =0Athe system were to be restarted before= > all of the log buffers 1-5 were=0Afully =0Aflushed, then you would lose th= > e transaction having the commit log=0Arecord in =0Abuffer 5 and that would > = > break the ACID rules of transactions. =0AAlso, if there are a large number > = > of log buffers and there is no control=0Aof =0Athe IO execution, then all > t= > hat youve done is to increase the IO=0Acontention on =0Athe log files, and > = > that would decrease performance. =0ASo the solution is probably not so > much= > just increasing the number of=0Alog =0Abuffers, but rather increasing the = > number of commits per log buffer=0Awhile =0Astill maintaining good > performa= > nce and functioning similar to unbuffered=0A=0Alogging. Perhaps not > allowin= > g the start of IO on buffer 2 until buffer 1=0Ais =0Acompletely flushed > AND= > allowing additional log records to be placed into=0A=0Abuffer 2 until the = > IO completion of log buffer 1. Yes - those=0Atransactions =0Athat placed a > = > commit log record into buffer 2 would have to be suspended=0Auntil =0Athe > I= > O completion of the IO on buffer 2 AND the IO would not be=0Ainitiated > =0Au= > ntil the completion of the IO on log buffer 1. =0AI dont know the > solution.= > I no longer have access to the source code to =0Aexperiment on a good solu= > tion to the problem. But again, Im not sure=0Athat the =0Aproblem is > stated= > in the RFE either. =0A=0ASent from Yahoo Mail for iPad =0A=0AOn Sunday, Ja= > nuary 7, 2018, 1:00 PM, Art Kagel <art.kagel@gmail.com>=0Awrote: > =0A=0AFOlk= > s: =0A=0AI submitted the following RFE to the IBM RFE Community site. If > yo= > u have=0Aan =0Ainterest in this feature/enhancement, please add your vote: > = > =0A=0A------------------------------------------------------------ > =0A-----= > --------------------------------------------------------- =0ANotification > g= > enerated at: 07 Jan 2018, 02:57 PM Eastern Time (ET) =0A=0AID: 114905 > =0AHe= > adline: Need the ability to increase =0Athe number of logical log buffers > f= > rom 3 to handle peak transaction=0Aloads =0ASubmitted on: 07 Jan 2018, > 02:5= > 7 PM Eastern Time =0A(ET) =0ABrand: Analytics Platform =0AProduct: > Informix=

Does the problem exist with buffered logging or only with unbuffered logging? If only with unbuffered logging, then that implies that the risk of the problem occurring increases as the efficiency of the log flush decreases. By efficiency, I mean the number of log records per log flush being higher. Buffered logging does increase the efficiency as is evident from the average number of pages per flush IO from onstat -l. Generally speaking unbuffered logging has far fewer pages per flush IO than buffered logging. Not only will that decrease the efficiency of the log flush, but it also increases the number of IO per minute. So in order to improve performance on the active transactional system, it would seem that the key would be to make the log flushing more efficient by increasing the log records per flush and decreasing the required number of IO. Mind you, Im not suggesting telling the customer to switch to buffered logging - just suggesting that some of the characteristics of buffered logging address some of the issue. I would also not suggest trying to implement exactly what buddy bunching commits that other DBMS have implemented. The archecture of IDS allows for very lite weight cooperation amongst threads that other DBMS dont readily have. Now for the HDR issue. Like the log flush, HDR has a single point bottleneck. With the log flush it is the amount of time that it takes to perform the physical IO and with HDR it is amount of time that it takes to send the HDR buffer across the network. By increasing the number of HDR transmit buffers, you not only increased the number of buffers on the primary, but also the number of buffers on the secondary. We did a lot of work in later versions of the server to improve the performance on the secondary so that we were not waiting so long for an IO completion to apply a log record. I dont know if the customer had that version of the server, but having additional buffers on the secondary would decrease the probability of a bottleneck that we had seen in receiving the log buffers. Since I didnt work the case, I dont know if the problem that the customer saw was a result of backflow caused by not being able to apply the log records or if it was a problem caused by the network transmission being too sluggish. Both cases would have resulted in the primary being unable to find an empty buffer. Just before I retired, we had addressed a problem with network transmission with RSS. This allowed us to have parallel transmission streams between primary and RSS secondary. This resulted in a significant improvement in synchronization after a long disconnect - on the order of 6-10 times faster. Just before I retired, I was thinking through the possibility of switch HDR so that it no longer used the half-duplex model that it used and instead using SMX so that we could move data to the secondary much quicker. But instead I focused on parallel shard queries. But then again, I no longer have acces to the code and cant experiment with a solution. So instead, Im currently boondocking in the Arizona desert... ;-) Sent from Yahoo Mail for iPad On Thursday, January 11, 2018, 1:37 AM, Fernando Nunes <domusonline@gmail.com> wrote: Trying to argue with two "monsters" (rest assured this is a compliment) is really a bold move. Please take this as food for thought, and not exactly as an educated opinion: Although the message misses some "newline" changes, and I didn't get the direct reply from Madison, I believe what he's suggesting is that the suggestion I made on the other RFE (group commit) would be a better solution. I was totally convinced about that, but a recent discussion with a person that was somehow involved with DB2 development (and mentioned that group commit caused issues...) raised some doubts. Apart from this, and considering Madison's points are very relevant (and didn't came to my mind innitially) I wonder if just increasing the number of buffers wouldn't help. Taking is example of flushing buffer "5" and how that would require previous flushes of buffers 1-4, we should not forget that it's the current situation we have with buffer "2" and "1", with the (big?) difference that currently we get into this as soon as we trigger a flush on buffer 3. So we only have one buffer before we get into the situation. With the considered scenario we would allow applications to "fill/flush" buffers 6-10 before getting into the issue. I wonder if that wouldn't help.... I do recall an ancient ATLAS case where from the description, a patch was created for an European customer to add more "HDR" buffers. And apparently that helped. It's not the same situation, but I wonder if the effect wouldn't be the same. But I guess that the folks from HCL reading this may consider that.... as long as there is a stress test, it shouldn't be too difficult to try... As to John's statement that "if it was easy, it would have been done before"... That causes me some "issues". I have a list of things that sound "easy" and were never implemented. I have two explanations for this: 1- My concept of "easy" doesn't always match reality. So good feedback like the one provided by Madison helps us, ignorant folks to understand why sometimes things are not that simple. And that feedback should be provided through the RFE system/process 2- Many times there's a huge gap between customer requirements and what's important for them, and the development priorities. This happens for a few reasons: The user's voice is not loud enough (and that's mainly their fault, but there's also a communication channel issue...). Development most of the times is concerned with what big customers want, and with what may gain us a new customer. I'm not criticizing this, but it has its disadvantages. 3- Many times, people that deal with big customers (mainly in the USA) have a privilege access to the development teams and managers, and they sometimes manage to use some "workarounds" that are "good enough". This is an obscure point, and a very personal "complaint" but let me illustrate with an example: What's the use for the common user of the "onstat -g pqs"? However for internal people the information may be very relevant. Regards. On Thu, Jan 11, 2018 at 7:31 AM, John Miller <jmiller@jfmiii.com> wrote: > =0AI would agree with my esteemed learned colleague. Increasing the=0Anumb= > er of log buffers will not help performance at all. If it would > have=0Athis= > would be an easy change which would have been done long ago. There=0Aare m= > any =0Aissues in dealing with the log buffer and Madison bring up one, but= > =0Athere =0Aare several more.=0A=0A=0AJohn=0A=0A-------- Original Message > -= > -------=0ASubject: Re: New RFE entry needs votes [40481]=0AFrom: "Madison > P= > ruet" <madison_pruet@yahoo.com>=0ADate: Wed, January 10, 2018 10:09 > pm=0ATo= > : ids@iiug.org=0A=0AIve been doing some thinking about this and would > like = > to make some =0Asuggestions. You can take it for what its worth. =0AIts > bes= > t to make a request for change to describe a problem and not so=0Amuch a = > =0Asolution. I dont thi