> Hmm. A further refinement would be to add a waiting-for-client-input
> bit to PROC, although if you have a fast-responding client, ignoring
> such backends wouldn't necessarily be a good thing. Notice that the
> pgbench transaction involves multiple client requests ...
>
> > 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.
>
> Yeah, because our attention hadn't been drawn to it. It won't escape
> so easily now ;-). The real concern here is that I'm not currently
> convinced that commit_delay = 0 is a good answer under heavy load.
OK, clearly your looking at the bit is better than what we have now, so
how about committing something that looks at the bit, but leave the
default at zero. Then, let people test zero and non-zero delays and
let's see what they find. That seems safe because we aren't enabling
the problematic delay by default, at least until we find it is a help in
most cases.
-- 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
