diff options
Diffstat (limited to 'doc/TODO.detail/mmap')
| -rw-r--r-- | doc/TODO.detail/mmap | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/doc/TODO.detail/mmap b/doc/TODO.detail/mmap index a57eed42547..fffd6333d39 100644 --- a/doc/TODO.detail/mmap +++ b/doc/TODO.detail/mmap @@ -240,3 +240,142 @@ It doesn't allow you to do several important optimizations. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster +From pgsql-general-owner+M14300@postgresql.org Mon Aug 27 13:07:32 2001 +Return-path: <pgsql-general-owner+M14300@postgresql.org> +Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f7RH7VF04800 + for <pgman@candle.pha.pa.us>; Mon, 27 Aug 2001 13:07:31 -0400 (EDT) +Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) + by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f7RH7Tq17721; + Mon, 27 Aug 2001 12:07:29 -0500 (CDT) + (envelope-from pgsql-general-owner+M14300@postgresql.org) +Received: from svana.org (svana.org [210.9.66.30]) + by postgresql.org (8.11.3/8.11.4) with ESMTP id f7RFE1f13269 + for <pgsql-general@postgresql.org>; Mon, 27 Aug 2001 11:14:01 -0400 (EDT) + (envelope-from kleptog@svana.org) +Received: from kleptog by svana.org with local (Exim 3.12 #1 (Debian)) + id 15bO5x-0000Fd-00; Tue, 28 Aug 2001 01:14:33 +1000 +Date: Tue, 28 Aug 2001 01:14:33 +1000 +From: Martijn van Oosterhout <kleptog@svana.org> +To: Andrew Snow <andrew@modulus.org> +cc: pgsql-general@postgresql.org +Subject: Re: [GENERAL] raw partition +Message-ID: <20010828011433.E32309@svana.org> +Reply-To: Martijn van Oosterhout <kleptog@svana.org> +References: <20010827233815.B32309@svana.org> <000101c12f00$dc5814b0$fa01b5ca@avon> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5i +In-Reply-To: <000101c12f00$dc5814b0$fa01b5ca@avon>; from andrew@modulus.org on Tue, Aug 28, 2001 at 12:02:08AM +1000 +Precedence: bulk +Sender: pgsql-general-owner@postgresql.org +Status: OR + +On Tue, Aug 28, 2001 at 12:02:08AM +1000, Andrew Snow wrote: +> +> What I think would be better would be moving postgresql to a system of +> using memory-mapped I/O. instead of the shared buffer cache, files +> would be directly memory-mapped and the OS would do the caching. I +> can't see this happening though because of platform dependancy, but I +> think its worth another look soon because many unix platforms support +> mmap(). I think it would improve the performance of disk-intensive +> tasks noticeably. + +Well, this has other problems. Consider tables that are larger than your +system memory. You'd have to continuously map and unmap different sections. +That can have odd side effects (witness mozilla on linux having 15,000 +mapped areas or so...) + +You would still however get the advantage that you wouldn't have to copy the +data from the disk buffers to user space, you simply get the disk buffer +mapped into your address space. + +I think that for commonly used tables that are under 100K in size (most of +the system tables), this is quite a workable idea. If you don't mind keeping +them mapped the whole time. + +-- +Martijn van Oosterhout <kleptog@svana.org> +http://svana.org/kleptog/ +> It would be nice if someone came up with a certification system that +> actually separated those who can barely regurgitate what they crammed over +> the last few weeks from those who command secret ninja networking powers. + +---------------------------(end of broadcast)--------------------------- +TIP 3: if posting/reading through Usenet, please send an appropriate +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-general-owner+M14319@postgresql.org Mon Aug 27 16:57:10 2001 +Return-path: <pgsql-general-owner+M14319@postgresql.org> +Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f7RKv9F16849 + for <pgman@candle.pha.pa.us>; Mon, 27 Aug 2001 16:57:09 -0400 (EDT) +Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) + by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f7RKv9q31456; + Mon, 27 Aug 2001 15:57:09 -0500 (CDT) + (envelope-from pgsql-general-owner+M14319@postgresql.org) +Received: from sss.pgh.pa.us ([192.204.191.242]) + by postgresql.org (8.11.3/8.11.4) with ESMTP id f7RJrsf55472 + for <pgsql-general@postgresql.org>; Mon, 27 Aug 2001 15:53:54 -0400 (EDT) + (envelope-from tgl@sss.pgh.pa.us) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id f7RJrGK19431; + Mon, 27 Aug 2001 15:53:16 -0400 (EDT) +To: Martijn van Oosterhout <kleptog@svana.org> +cc: Andrew Snow <andrew@modulus.org>, pgsql-general@postgresql.org +Subject: Re: [GENERAL] raw partition +In-Reply-To: <20010828011433.E32309@svana.org> +References: <20010827233815.B32309@svana.org> <000101c12f00$dc5814b0$fa01b5ca@avon> <20010828011433.E32309@svana.org> +Comments: In-reply-to Martijn van Oosterhout <kleptog@svana.org> + message dated "Tue, 28 Aug 2001 01:14:33 +1000" +Date: Mon, 27 Aug 2001 15:53:15 -0400 +Message-ID: <19428.998941995@sss.pgh.pa.us> +From: Tom Lane <tgl@sss.pgh.pa.us> +Precedence: bulk +Sender: pgsql-general-owner@postgresql.org +Status: OR + +Martijn van Oosterhout <kleptog@svana.org> writes: +> You would still however get the advantage that you wouldn't have to copy the +> data from the disk buffers to user space, you simply get the disk buffer +> mapped into your address space. + +AFAICS this would be the *only* advantage. While it's not negligible, +it's quite unclear that it's worth the bookkeeping and portability +headaches of managing lots of mmap'd areas, either. + +Before I take this idea seriously at all, I'd want to see a design that +addresses a couple of critical issues: + +1. Postgres' shared buffers are *shared*, potentially across many +processes. How will you deal with buffers for files that have been +mmap'd by only some of the processes? (Maybe this means that the +whole concept of shared buffers goes away, and each process does its +own buffer management based on its own mmaps. Not sure. That would be +a pretty radical restructuring though, and would completely invalidate +our present approach to page-level locking.) + +2. How do you deal with extending a file? My system's mmap man page +says + If the size of the mapped file changes after the call to mmap(), the + effect of references to portions of the mapped region that correspond + to added or removed portions of the file is unspecified. +This suggests that the only portable way to cope is to issue a separate +mmap for every disk page. Will typical Unix systems perform well with +umpteen thousand small mmap requests? + +3. How do you persuade the other backends to drop their mmaps of a table +you are deleting? + +There are probably other gotchas, but without an understanding of how +to address these, I doubt it's worth looking further ... + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html + |