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?
> With xlog on a FAT file system, I can get 53-60 sets per second. With Xlog
> sitting on ext2, I can get 40-45 sets per second. (Of the same data) These are
> not insignificant improvements, and should be examined. If not from a Postgres
> development perspective, at least from a deployment perspective.
Yes, therefore a proposed a 'knowledge-base' where such things
could be mentioned.
--
marko
