| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Curtis Faith" <curtis(at)galtair(dot)com> |
| Cc: | "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Potential Large Performance Gain in WAL synching |
| Date: | 2002-10-04 04:50:41 |
| Message-ID: | 17503.1033707041@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Curtis Faith" <curtis(at)galtair(dot)com> writes:
> The REAL issue and the one that will greatly affect total system
> throughput is that of contention on the file locks. Since fsynch needs to
> obtain a write lock on the file descriptor, as does the write calls which
> originate from XLogWrite as the writes are written to the disk, other
> back-ends will block while another transaction is committing if the
> log cache fills to the point where their XLogInsert results in a
> XLogWrite call to flush the log cache.
But that's exactly *why* we have a log cache: to ensure we can buffer a
reasonable amount of log data between XLogFlush calls. If the above
scenario is really causing a problem, doesn't that just mean you need
to increase wal_buffers?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-10-04 04:53:15 | Re: Return of INSTEAD rules |
| Previous Message | Bruce Momjian | 2002-10-04 04:47:37 | Re: Return of INSTEAD rules |