Re: File system performance and pg_xlog

Marko Kreen <marko(at)l-t(dot)ee> writes:

> On Sat, May 05, 2001 at 10:10:33PM -0400, mlw wrote:
> > I think it is simpler problem than that. Postgres, with fsync enabled, does a
> > lot of work trying to maintain data integrity. It is logical to conclude that a
> > file system that does as little as possible would almost always perform better.
> > Regardless of what the file system does, eventually it writes blocks of data to
> > sectors on a disk.
>
> But there's more, when PostgreSQL today 'uses a fs' it also get
> all the caching/optimizing algorithms in os kernel 'for free'.
>
> > Many databases use their own data volume management. I am not suggesting that
> > anyone create a new file system, but after performing some tests, I am really
> > starting to see why products like oracle manage their own table spaces.
> >
> > If one looks at the FAT file system with an open mind and a clear understanding
> > of how it will be used, some small modifications may make it the functional
> > equivalent of a managed table space volume, at least under Linux.
>
> Are you talking about new in-kernel fs? Lets see, how many
> os'es PostgreSQL today supports?

If you're using raw devices on Linux and get a win there, it's a win
for Postgresql on Linux. This is important for everyone using it on
this platform (probably a big chunk of the users). And who uses all
the new features and performance enhancements done in other ways?

It all comes down to if it actually would give a performance boost,
how much work it is and if someone wants to do it.
>

--
Trond Eivind Glomsrød
Red Hat, Inc.