From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: reiser4 performance Date: Mon, 08 Aug 2005 16:30:43 -0700 Message-ID: <42F7EB23.7030301@namesys.com> References: <42F7A01A.7090209@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" To: Gregory Maxwell Cc: ReiserFS List Gregory Maxwell wrote: >On 8/8/05, Hans Reiser wrote: > > >>I should add that fsync performance has not been worked on yet, which is >>surely why postgres performance is poor. >> >> > >Hans, I'm on the postgresql hackers list (although I don't really have >a voice there, so I can't really speak much for reiser4 there).. > >One of the 'interesting' issues they face is that that postgresql >database works with 8K pages. From a performance and reliability >perspective they would benefit impressively from a file system (and >VFS) which could atomically update their 8k pages. Without such a >feature their performance is slaughtered when operating in a mode that >provides the highest reliability, and their reliability is slaughtered >when operating in the highest performance configuration. > >I'm sure the PostgreSQL folks would be here themselves asking for help >with this issue... if they weren't so oriented around FreeBSD. :) > >If ever you are looking for a killer app for Reiser4 that people who >don't care about the visionary stuff will care about: you couldn't >find one better than postgresql. If you could get postgresql working >as reliably as a double logged full fsync configuration but performing >as fast as a configuration with async writes.... you'd have a lot more >supporters. > > > > Well I would be very happy to do that. In fact, if they use 8k writes, we already do that. If they need to use mmap while being atomic, well, that is more complex, and if someone sponsors it we will do it. Right now we don't have much resources to spare as we complete the work needed to go into the kernel. Thanks for a very interesting remark.... Hans