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
