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
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 |