Re: Re: New Linux xfs/reiser file systems

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
Cc: mlw <markw(at)mohawksoft(dot)com>, Thomas Swan <tswan(at)ics(dot)olemiss(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Re: New Linux xfs/reiser file systems
Date: 2001-05-06 12:04:28
Message-ID: 3AF53DCC.A1E3646@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ? ;)

It may be much easier to implement than a full fs.

How hard would it be to let wal reside on a (raw) device ?

If we already pre-allocate a required number of fixed-size files would
it be too
hard to replace them with plain (raw) devices and test for possible
performance gains ?

>
> How about naming the DB objects <object ID>.<object name>?
> e.g
>
> 121575.testtable
> 125575.testtableindex
>

This sure seems to be an elegant solution for the problem that seems to
be impossible
to solve with symlinks and such. Even the IMHO hardest to solve problem
- RENAME - can
probably be done in a transaction-safe manner by doing a
link(oid.<newname>) in the
beginning and selective unlink(oid.<newname/oldname>) at commit time.

--------------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2001-05-06 12:53:56 Re: New Linux xfs/reiser file systems
Previous Message Lincoln Yeoh 2001-05-06 11:24:43 Re: New Linux xfs/reiser file systems