Re: sync_file_range() - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: sync_file_range()
Date
Msg-id 1150793092.2587.134.camel@localhost.localdomain
Whole thread Raw
In response to Re: sync_file_range()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sync_file_range()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2006-06-19 at 21:35 -0400, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > Come to think of it I wonder whether there's anything to be gained by using
> > smaller files for tables. Instead of 1G files maybe 256M files or something
> > like that to reduce the hit of fsyncing a file.

> sync_file_range() is not that exactly, but since it lets you request
> syncing and then go back and wait for the syncs later, we could get the
> desired effect with two passes over the file list.  (If the file list
> is longer than our allowed number of open files, though, the extra
> opens/closes could hurt.)

So we would use the async properties of sync, but not the file range
support? Sounds like it could help with multiple filesystems.

> Indeed, I've been wondering lately if we shouldn't resurrect
> LET_OS_MANAGE_FILESIZE and make that the default on systems with
> largefile support.  If nothing else it would cut down on open/close
> overhead on very large relations.

Agreed.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: PAM auth
Next
From: Simon Riggs
Date:
Subject: Re: shall we have a TRACE_MEMORY mode