X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 338989FB3A0 for ; Fri, 22 Sep 2006 00:41:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 97653-08-3 for ; Fri, 22 Sep 2006 03:41:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.envysolutions.com (mark.mielke.cc [206.248.142.186]) by postgresql.org (Postfix) with ESMTP id 771059FB3FE for ; Fri, 22 Sep 2006 00:40:39 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id B46825403E; Thu, 21 Sep 2006 23:40:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.envysolutions.com Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECqgzZbPOcHE; Thu, 21 Sep 2006 23:40:37 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 74E7C5403F; Thu, 21 Sep 2006 23:40:37 -0400 (EDT) Date: Thu, 21 Sep 2006 23:40:37 -0400 From: mark@mark.mielke.cc To: Guy Thornley Cc: Markus Schaber , Luke Lonergan , pgsql-performance@postgresql.org Subject: Re: Large tables (was: RAID 0 not as fast as Message-ID: <20060922034037.GB2820@mark.mielke.cc> References: <45123FC0.9060100@logix-tt.com> <20060922025209.GO6211@esphion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060922025209.GO6211@esphion.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.094 tagged_above=0 required=5 tests=FORGED_RCVD_HELO, NO_REAL_NAME, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * X-Archive-Number: 200609/293 X-Sequence-Number: 20979 On Fri, Sep 22, 2006 at 02:52:09PM +1200, Guy Thornley wrote: > > >> I thought that posix_fadvise() with POSIX_FADV_WILLNEED was exactly > > >> meant for this purpose? > > > This is a good idea - I wasn't aware that this was possible. > > This possibility was the reason for me to propose it. :-) > posix_fadvise() features in the TODO list already; I'm not sure if any work > on it has been done for pg8.2. > > Anyway, I understand that POSIX_FADV_DONTNEED on a linux 2.6 kernel allows > pages to be discarded from memory earlier than usual. This is useful, since > it means you can prevent your seqscan from nuking the OS cache. > > Of course you could argue the OS should be able to detect this, and prevent > it occuring anyway. I don't know anything about linux's behaviour in this > area. I recall either monitoring or participating in the discussion when this call was added to Linux. I don't believe the kernel can auto-detect that you do not need a page any longer. It can only prioritize pages to keep when memory is fully in use and a new page must be loaded. This is often some sort of LRU scheme. If the page is truly useless, only the application can know. I'm not convinced that PostgreSQL can know this. The case where it is useful is if a single process is sequentially scanning a large file (much larger than memory). As soon as it is more than one process, or if it is not a sequential scan, or if it is not a large file, this call hurts more than it gains. Just because I'm done with the page does not mean that *you* are done with the page. I'd advise against using this call unless it can be shown that the page will not be used in the future, or at least, that the page is less useful than all other pages currently in memory. This is what the call really means. It means, "There is no value to keeping this page in memory". Perhaps certain PostgreSQL loads fit this pattern. None of my uses fit this pattern, and I have trouble believing that a majority of PostgreSQL loads fits this pattern. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/