> Bruce Momjian <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
