Re: File system performance and pg_xlog
От | teg@redhat.com (Trond Eivind Glomsrød) |
---|---|
Тема | Re: File system performance and pg_xlog |
Дата | |
Msg-id | xuyae4pyzjt.fsf@halden.devel.redhat.com обсуждение исходный текст |
Ответ на | Re: File system performance and pg_xlog (Marko Kreen <marko@l-t.ee>) |
Ответы |
Re: File system performance and pg_xlog
|
Список | pgsql-hackers |
Marko Kreen <marko@l-t.ee> writes: > On Sat, May 05, 2001 at 10:10:33PM -0400, mlw wrote: > > I think it is simpler problem than that. Postgres, with fsync enabled, does a > > lot of work trying to maintain data integrity. It is logical to conclude that a > > file system that does as little as possible would almost always perform better. > > Regardless of what the file system does, eventually it writes blocks of data to > > sectors on a disk. > > But there's more, when PostgreSQL today 'uses a fs' it also get > all the caching/optimizing algorithms in os kernel 'for free'. > > > Many databases use their own data volume management. I am not suggesting that > > anyone create a new file system, but after performing some tests, I am really > > starting to see why products like oracle manage their own table spaces. > > > > If one looks at the FAT file system with an open mind and a clear understanding > > of how it will be used, some small modifications may make it the functional > > equivalent of a managed table space volume, at least under Linux. > > Are you talking about new in-kernel fs? Lets see, how many > os'es PostgreSQL today supports? If you're using raw devices on Linux and get a win there, it's a win for Postgresql on Linux. This is important for everyone using it on this platform (probably a big chunk of the users). And who uses all the new features and performance enhancements done in other ways? It all comes down to if it actually would give a performance boost, how much work it is and if someone wants to do it. > -- Trond Eivind Glomsrød Red Hat, Inc.
В списке pgsql-hackers по дате отправления: