X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id A044FD1C9BD for ; Mon, 9 Feb 2004 21:42:36 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 47530-02 for ; Mon, 9 Feb 2004 17:42:29 -0400 (AST) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by svr1.postgresql.org (Postfix) with SMTP id 0479AD1DAA6 for ; Mon, 9 Feb 2004 17:42:27 -0400 (AST) Received: from unknown (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp017.mail.yahoo.com with SMTP; 9 Feb 2004 21:42:28 -0000 Received: from Yahoo.com (ismtp.afilias.com [216.217.55.254]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id i19Lgik06680; Mon, 9 Feb 2004 16:42:44 -0500 Message-ID: <4027F063.8020506@Yahoo.com> Date: Mon, 09 Feb 2004 15:41:07 -0500 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stark Cc: pgsql-hackers@postgresql.org Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint References: <200402080144.i181ija15739@candle.pha.pa.us> <40279A25.6020600@Yahoo.com> <87r7x4m5uy.fsf@stark.xeocode.com> In-Reply-To: <87r7x4m5uy.fsf@stark.xeocode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/360 X-Sequence-Number: 49949 Greg Stark wrote: > Jan Wieck writes: > >> The whole sync() vs. fsync() discussion is in my opinion nonsense at this >> point. Without the ability to limit the amount of files to a reasonable number, >> by employing tablespaces in the form of larger container files, the risk of >> forcing excessive head movement is simply too high. > > I don't think there was any suggestion of conflating tablespaces with > implementing a filesystem in postgres. > > Tablespaces are just a database entity that database stored objects like > tables and indexes are associated to. They group database stored objects and > control the storage method and location. > > The existing storage mechanism, namely a directory with a file for each > database object, is perfectly adequate and doesn't have to be replaced to > implement tablespaces. All that's needed is that the location of the directory > be associated with the "tablespace" of the object rather than be a global > constant. > > Implementing an Oracle-style filesystem is just one more temptation to > reimplement OS services in the database. Personally I think it's an awful > idea. But even if postgres did it as an option, it wouldn't necessarily have > anything to do with tablespaces. > Doing this is not just what you call it. In a system with let's say 500 active backends on a database with let's say 1000 things that are represented as a file, you'll need half a million virtual file descriptors. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #