Re: CommitDelay performance improvement

> At 21:31 23/02/01 -0500, Bruce Momjian wrote:
> >Now, I know many will complain that we are returning commit while not
> >having the stuff on the platter.
>
> You're definitely right there.
>
> >Maybe they do, but it seems
> >the benefit of grouped fsyncs() is large enough that many will say they
> >would rather have this option.
>
> I'd prefer to wait for a lock manager that supports timeouts and contention
> notification.
>

There is one more thing. Even though the kernel says the data is on the
platter, it still may not be there. Some OS's may return from fsync
when the data is _queued_ to the disk, rather than actually wanting for
the drive return code to say it completed. Second, some disks report
back that the data is on the disk when it is actually in the disk memory
buffer, not really on the disk.

Basically, I am not sure how much we lose by doing the delay after
returning COMMIT, and I know we gain quite a bit by enabling us to group
fsync calls.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026