On Mon, Dec 6, 2010 at 10:47 AM, Rob Wultsch <wultsch@xxxxxxxxx> wrote: > On Sun, Dec 5, 2010 at 7:30 PM, Jignesh Shah <jkshah@xxxxxxxxx> wrote: >> The commit_siblings = 5 basically checks that it sleeps only when that >> many backends are active. This I think is a very expensive check and I >> would rather make commit_siblings=0 (which the current code does not >> support.. it only supports minimum of 1) The check is expensive >> irrespective of the settings .. But anyway here is the real kicker. >> In all the tests I did with recent verions 8.4 and version 9.0 , it >> seems that the default behavior handles the load well enough and one >> does not have to use commit_delay at all. Since when the load is very >> high all of them are basically in sync phase and the desired thing >> happens anyway. >> >> Infact using commit_delay will actually add the cost of doing >> commit_siblings check and can hurt the performance by increasing CPU >> consumption.. Doing commit_siblings check for every transaction is a >> killer since it does not return after meeting the minimum backends and >> goes through every backend to calculate the total number before >> comparing with the minimum. This is probably why most people see a >> drop in performance when using commit_delay compared to the default. >> >> Anyway I would recommended right now to stick with the default and >> not really use it. It does the sync absorbtion well if you have two >> many users (though not perfect). > > Sounds like this setting should go away unless there is a very good > reason to keep it. > > > -- > Rob Wultsch > wultsch@xxxxxxxxx > I would say commit_siblings should go away but maybe keep commit_delay for a while. The advantage of keeping commit_delay is to do a rhythmic write patterns which can be used to control writes on WAL. It is debatable but I had used it couple of times to control WAL writes. To me commit_siblings is expensive during heavy users/load and should be killed. My 2 cents. Regards, Jignesh -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
