Re: Utilizing "direct writes" Re: File system performance and pg_xlog - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Utilizing "direct writes" Re: File system performance and pg_xlog
Date
Msg-id 20010506123448.B20919@l-t.ee
Whole thread Raw
In response to Utilizing "direct writes" Re: File system performance and pg_xlog  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: Utilizing "direct writes" Re: File system performance and pg_xlog  (Alfred Perlstein <bright@wintelcom.net>)
List pgsql-hackers
On Sat, May 05, 2001 at 07:01:35PM -0700, Alfred Perlstein wrote:
> * Marko Kreen <marko@l-t.ee> [010505 17:39] wrote:
> > * double-buffering and incompatibilities of avoiding that
> 
> Depends on the OS, most Operating systems like FreeBSD and Solaris
> offer character device access, this means that the OS will DMA
> directly from the process's address space.  Avoiding the double
> copy is trivial except that one must align and size writes correctly,
> generally on 512 byte boundries and in 512 byte increments.

PostgreSQL must then also think about write ordering very hard,
atm this OS business.

> > * the speed difference will not be very big.  Remeber: it _was_
> >   big on OS'es and fs' in year 1990.  Today's fs are lot of
> >   better and there should be a os/fs combo that is 95% perfect.
> 
> Well, here's an idea, has anyone tried using the "direct write"
> interface that some OS's offer?  I doubt FreeBSD does, but I'm
> positive that Solaris offers it as well as possibly IRIX.

And how much it differs from using FAT?  Thats the point I
want to make.  There should be already a fs that is 90% close
that.

-- 
marko



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: MULTIBYTE and SQL_ASCII (was Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?)
Next
From: Marko Kreen
Date:
Subject: Re: Lisp as procedural language