Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | CAA4eK1+nSab4hXqTUrnXkrnjS_Z3Z4Aaa=MFzoU26jc17aiybQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers
|
Список | pgsql-hackers |
On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapila16@gmail.com> writes: >> Just to let you know that I think I have figured out the reason of >> failure. If we run the regressions with attached patch, it will make >> the regression tests fail consistently in same way. The patch just >> makes all transaction status updates to go via group clog update >> mechanism. > > This does *not* give me a warm fuzzy feeling that this patch was > ready to commit. Or even that it was tested to the claimed degree. > I think this is more of an implementation detail missed by me. We have done quite some performance/stress testing with a different number of savepoints, but this could have been caught only by having Rollback to Savepoint followed by a commit. I agree that we could have devised some simple way (like the one I shared above) to test the wide range of tests with this new mechanism earlier. This is a learning from here and I will try to be more cautious about such things in future. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: