Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2C61C2E005A for ; Tue, 25 Mar 2008 11:03:22 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 92813-10 for ; Tue, 25 Mar 2008 11:03:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id 2769C2E0056 for ; Tue, 25 Mar 2008 11:03:13 -0300 (ADT) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 25 Mar 2008 10:03:13 -0400 id 0005641C.47E90621.000102BC Date: Tue, 25 Mar 2008 10:03:15 -0400 From: Bill Moran To: "sathiya psql" Cc: pgsql-performance@postgresql.org Subject: Re: postgresql is slow with larger table even it is in RAM Message-Id: <20080325100315.a5435381.wmoran@collaborativefusion.com> In-Reply-To: References: <20080325091046.b5d50a35.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/477 X-Sequence-Number: 29431 In response to "sathiya psql" : > > > > Yes. It takes your hardware about 3 seconds to read through 700M of ram. > > > > > > Keep in mind that you're not just reading RAM. You're pushing system > > requests through the VFS layer of your operating system, which is treating > > the RAM like a disk (with cylinder groups and inodes and blocks, etc) so > > you have all that processing overhead as well. What filesystem did you > > format the RAM disk with? > > tmpfs I'm not an expert, but according to wikipedia: "tmpfs (previously known as shmfs) distinguishes itself from the Linux ramdisk device by allocating memory dynamically and by allowing less-used pages to be moved onto swap space." Both dynamically allocating and swapping are potential problems, but I don't know how to tell you to determine if they're issues or not. > > Why are you doing this? If you have enough RAM to store the table, why > > not just allocate it to shared buffers? > > just allocating will make read from hdd to RAM at first time, to eliminate > that PostgreSQL is still going to copy the data from your RAM disk into shared buffers before working with it, so you still have that overhead. All you're escaping is the time involved in physical disk activity, which is what shared_buffers are designed to avoid. > are you saying it will take 3 seconds surely if i have 50 lakh record No. That is dependent on your hardware and other factors. You are trying to use the system in a non-standard configuration. If it doesn't work that way, don't be surprised. Also, what are you expectations? Honestly, I don't see any problems with the results you're getting, they're about what I would expect. Are you trying to compare PostgreSQL to MySQL/MyISAM? More directly, what is your purpose in starting this email conversation? What are you hoping to accomplish? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023