X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 132C6D783A for ; Fri, 2 Sep 2005 15:00:55 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 32384-03 for ; Fri, 2 Sep 2005 18:00:50 +0000 (GMT) Received: from mail.travelamericas.com (unknown [206.130.134.147]) by svr1.postgresql.org (Postfix) with SMTP id E1032D76CC for ; Fri, 2 Sep 2005 15:00:48 -0300 (ADT) Received: (qmail 13806 invoked from network); 2 Sep 2005 18:00:48 -0000 Received: from unknown (HELO ?10.0.0.253?) (10.0.0.253) by verkiel.travelamericas.com with SMTP; 2 Sep 2005 18:00:48 -0000 Message-ID: <4318934E.7070404@travelamericas.com> Date: Fri, 02 Sep 2005 11:00:46 -0700 From: Chris Travers User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Akshay Mathur Cc: 'Ron' , pgsql-performance@postgresql.org Subject: Re: Massive performance issues References: <002901c5afa0$0dcddab0$8301a8c0@pune.wibhu.com> In-Reply-To: <002901c5afa0$0dcddab0$8301a8c0@pune.wibhu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.026 required=5 tests=[AWL=0.026] X-Spam-Level: X-Archive-Number: 200509/61 X-Sequence-Number: 14369 Akshay Mathur wrote: >Ron, > >Can you give me some pointers to make the tables RAM resident. If one >does so, is the program accessing the data need to change. Does pgsql >take care to write the data to disk? > > > PostgreSQL tried to intelligently cache information and then will also use the OS disk cache as a secondary cache. So a sufficiently small and frequently accessed table will be resident in RAM. The simplest way to affect this calculus is to put more RAM in the machine. There are hacks I can think of to create RAM caches of specific tables, but I don't want to take responsibility for anyone trying these and running into trouble. Best Wishes, Chris Travers Metatron Technology Consulting