Re: Re: New Linux xfs/reiser file systems
От | Hannu Krosing |
---|---|
Тема | Re: Re: New Linux xfs/reiser file systems |
Дата | |
Msg-id | 3AF53DCC.A1E3646@tm.ee обсуждение исходный текст |
Ответ на | Re: Re: New Linux xfs/reiser file systems (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Re: New Linux xfs/reiser file systems
Re: Re: New Linux xfs/reiser file systems |
Список | 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
В списке pgsql-hackers по дате отправления: