Hannu Krosing wrote:
>
> Lincoln Yeoh wrote:
> >
> > At 01:16 PM 5/5/01 -0400, mlw wrote:
> > >Lincoln Yeoh wrote:
> > >>
> > >> All that for maybe 10% performance increase?
> > >>
> > >> I think it's more advantageous for Postgresql to keep the filesystem layer
> > >> of abstraction, than to do away with it, and later reinvent certain parts
> > >> of it along with new bugs.
> > >
> > >I just did a test of putting pg_xlog on a FAT file system, and my first rough
> > >tests (pgbench) show an approximate 20% performance increase over ext2 with
> > >fsync enabled.
> >
> > OK. I slouch corrected :). It's more than 10%.
> >
> > However in the same message I did also say:
> > >What would be useful is if one can specify where the tables, indexes, WAL
> > >and other files go. That feature would probably help improve performance
> > >far more.
> > >
> > >For example: you could then stick the WAL on a battery backed up RAM disk.
> > >How much total space does a WAL log need?
> > >
> > >A battery backed RAM disk might even be cheaper than Brand X RDBMS
> > >Proprietary Feature #5.
> >
> > And your experiments do help show that it is useful to be able to specify
> > where things go, that putting just the WAL somewhere else makes things 20%
> > faster. So you don't have to put everything on a pgfs. Just the WAL on some
> > other FS (even FAT32, ick ;) ).
>
> So you propose pgwalfs ? ;)
I don't know about a "pgwalfs" too much work. I have had some time to grapple
with my feelings about FAT, and you know what? I don't hate the idea. I would,
of course, like to look through the driver code and see if there are any
technical reasons why it should be excluded.
FAT is almost perfect for WAL, and if I can figure out how to get the "base"
directory to get the same performance, I'd think about putting it there as
well.
The ReiserFS issues touched on some vague suspicions I had about fsync. Maybe
I'm over reacting, but there are reasons why the oracles manage their own table
spaces.
Back to FAT. FAT is probably the most simple file system I can think of. As
long as it writes to disk when it gets synched, and doesn't loose things, its
perfect. Postgres maintains much of the coherency issues, there is no real
problem with permissions because it will be owned by the postgres super user,
etc. I would never suggest FAT as a general purpose file system, but, geez, as
a special purpose single user (postgres) it seems an ideal answer to what will
be an increasingly hard problem of advanced file systems.
Aside from a general, and well deserved, disdain for FAT. What are the
technical "cons" of such a proposal. If we can get the Linux kernel (and other
unices) to accept IOCTLs to direct space allocation, and/or write up a white
paper on how to use this for postgres, why wouldn't it be a reasonable
strategy?
--
I'm not offering myself as an example; every life evolves by its own laws.
------------------------
http://www.mohawksoft.com
