Skip site navigation (1) Skip section navigation (2)

Re: CommitDelay performance improvement

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommitDelay performance improvement
Date: 2001-02-24 04:14:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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                        |
  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

In response to


pgsql-hackers by date

Next:From: Nathan MyersDate: 2001-02-24 04:24:40
Subject: Re: CommitDelay performance improvement
Previous:From: Bruce MomjianDate: 2001-02-24 04:03:40
Subject: Re: CommitDelay performance improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group