X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C74D552F05 for ; Thu, 11 Aug 2005 20:13:29 -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 12193-08 for ; Thu, 11 Aug 2005 23:13:27 +0000 (GMT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by svr1.postgresql.org (Postfix) with ESMTP id F307252F3C for ; Thu, 11 Aug 2005 20:13:25 -0300 (ADT) Received: from [192.168.1.52] (c-24-60-119-214.hsd1.ma.comcast.net[24.60.119.214]) by comcast.net (sccrmhc14) with ESMTP id <2005081123132801400k49ene>; Thu, 11 Aug 2005 23:13:28 +0000 Message-ID: <42FBDB97.1010906@comcast.net> Date: Thu, 11 Aug 2005 19:13:27 -0400 From: Jeffrey Tenny User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John A Meinel Cc: pgsql-performance@postgresql.org Subject: Re: Mostly read performance References: <42FBCF4D.6060002@comcast.net> <42FBD377.8040006@arbash-meinel.com> In-Reply-To: <42FBD377.8040006@arbash-meinel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.562 tagged_above=0 required=5 tests=[AWL=-0.680, DNS_FROM_RFC_ABUSE=0.374, DNS_FROM_RFC_POST=1.376, DNS_FROM_RFC_WHOIS=0.492] X-Spam-Level: * X-Archive-Number: 200508/136 X-Sequence-Number: 13883 John A Meinel wrote: > Well, first off, the general recommendation is probably that 7.3 is > really old, and you should try to upgrade to at least 7.4, though > recommended to 8.0. There have been issues with each release that led me to wait. Even now I'm waiting for some things to settle in the 8.0 JDBC driver (timezones), and 7.3 has behaved well for me. But yes, I'd like to upgrade. > > The bigger questions: How much RAM do you have? How busy is your system? The system for testing was 512MB. I'm in the process of buying some additional memory. However there was no swap activity on that system, so I doubt memory was the limiting factor. > > 8.0 doesn't really do anything to do make the system cache the data. > What kernel are you using? 2.4.X for various large x. (Multiple systems). Gonna try 2.6.x soon. > > Also, if your tables are small enough, and your RAM is big enough, you > might already have everything cached. Well, that's what you'd expect. But a first time 70MB fetch on a freshly rebooted system took just as long as all secondary times. (Took over a minute to fetch, which is too long for my needs, at least on secondary attempts). > One way to flush the caches, is to allocate a bunch of memory, and then > scan through it. Or maybe mmap a really big file, and access every byte. > But if your kernel is smart enough, it could certainly deallocate pages > after you stopped accessing them, so I can't say for sure that you can > flush the memory cache. Usually, I believe these methods are sufficient. Not sure how that would really help. It doesn't seem like the database or file system is caching the table content either way, which led me to this inquiry.