| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FYI: fdatasync vs sync_file_range |
| Date: | 2009-07-06 10:25:59 |
| Message-ID: | 1246875959.27964.785.camel@dn-x300-willij |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2009-07-06 at 17:54 +0900, Fujii Masao wrote:
> According to the result, using sync_file_range instead of fdatasync
> has little effect in the performance of postgres.
["...when flushing XLOG"]
Why did you think it would?
AFAICS the range of dirty pages will be restricted to a fairly tight
range anyway. The only difference between the two would indicate an OS
inefficiency. I don't see an opportunity for XLOG to be more efficient
by using a finer-grained API.
I think there is still a valid use for sync_file_range at checkpoint,
since the for some large tables this could reduce the number of pages
needing to be written at checkpoint time. That would help smooth out
larger writes.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Itagaki Takahiro | 2009-07-06 10:28:57 | ALTER SET DISTINCT vs. Oracle-like DBMS_STATS |
| Previous Message | Heikki Linnakangas | 2009-07-06 10:01:26 | Re: FYI: fdatasync vs sync_file_range |