Re: beta5 packages ...
От | Bruce Momjian |
---|---|
Тема | Re: beta5 packages ... |
Дата | |
Msg-id | 200102232146.QAA29601@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: beta5 packages ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Commit delay (was Re: beta5 packages)
|
Список | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think we need to give up on the delay for 7.1.X. I don't see any > > good/easy solutions. > > I take it you think my idea is not even worth trying. Why not? You are suggesting looking at the "I have modified something" bit in Proc, and using that to trigger the delay, right? Well, clearly it would help because a single backend would not do any delay, however, that is the same as doing a zero delay all the time, which is what we are doing now. So, the change would have to show that doing the delay when some other backend has dirtied a buffer is _better_ than doing no delay. I guess the question is "What is the average time from that bit being set to the actual commit, and what is its relation to the duration of an fsync()?" If the bit set/commit time is small by comparison, it would be worth using the bit. However, we have also seen that the delay itself is usually 10ms, which is pretty long by itself. Your bit does allow us to _not_ wait if there aren't other backends in process, which is a good thing. OK, let's look at the average duration from bit set to commit. If the user is in a multi-statement transaction, the delay could be quite long. If they are doing an UPDATE/DELETE that is doing a sequential scan, that will be long too. If they are doing an INSERT, that should be quick, though INSERT/SELECT could be long. I guess the 10ms minimum delay time is a problem for me. The good thing is that this delay happens _only_ if other backends are actually running, though if someone is sitting in psql and the are inside a transaction, that is going to cause a wait too. Let's keep talking. I see us so near release, I am not sure if we can get something that is a clear win, and we saw how the 5us fix almost got out in the final before we realized the performance problems with it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: