"Tom Lane" <[EMAIL PROTECTED]> writes:
> > 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.
>
> > I'd s
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> 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.
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> So we would use the async properties of sync, but not the file range
> support?
That's the part of it that looked potentially useful to me, anyway.
I don't see any value for us in syncing just part of a file, because
we don't have enough disk layout knowle
> > 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.
I'd still put some limit on the filesize, else you
On Mon, 2006-06-19 at 21:35 -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> 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 f
Greg Stark <[EMAIL PROTECTED]> 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.
Actually probably not. The weak part of our current
On Mon, 2006-06-19 at 15:04 -0400, Greg Stark wrote:
> > We fsync the xlog at transaction commit, so only the leading edge needs
> > to be synced - would the call help there? Presumably the OS can already
> > locate all blocks associated with a particular file fairly quickly
> > without doing a fu
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-06-19 at 15:32 +0800, Qingqing Zhou wrote:
> > "ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
> > >
> > >
> > > I'm interested in it, with which we could improve responsiveness during
> > > checkpoints. Though it is Linux specific system call, b
* Simon Riggs:
> Other files are fsynced at checkpoint - always all dirty blocks in the
> whole file.
Optionally, sync_file_range does not block the calling process, so
it's very easy to flush all files at once, which could in theory
reduce seeking overhead.
---(end of br
On Mon, 2006-06-19 at 15:32 +0800, Qingqing Zhou wrote:
> "ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
> >
> >
> > I'm interested in it, with which we could improve responsiveness during
> > checkpoints. Though it is Linux specific system call, but we could use
> > the combination of mmap() and msy
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote:
> > I'm interested in it, with which we could improve responsiveness during
> > checkpoints. Though it is Linux specific system call, but we could use
> > the combination of mmap() and msync() instead of it; I mean we can use
> > mmap only to flush dirty
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> wrote
>
>
> I'm interested in it, with which we could improve responsiveness during
> checkpoints. Though it is Linux specific system call, but we could use
> the combination of mmap() and msync() instead of it; I mean we can use
> mmap only to flush dirty pa
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> http://lwn.net/Articles/178199/
> Check out the article on sync_file_range():
> Is that at all useful for PostgreSQL's purposes?
I'm interested in it, with which we could improve responsiveness during
checkpoints. Though it is Linux specific s
http://lwn.net/Articles/178199/
Check out the article on sync_file_range():
long sync_file_range(int fd, loff_t offset, loff_t nbytes, int flags);
This call will synchronize a file's data to disk, starting at the given
offset and proceeding for nbytes bytes (or to the end of the file if
14 matches
Mail list logo
