Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 34D8F2E002C
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 25 Mar 2008 10:27:20 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 54106-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 25 Mar 2008 10:27:05 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227])
	by postgresql.org (Postfix) with ESMTP id B90DC2E0042
	for <pgsql-performance@postgresql.org>;
	Tue, 25 Mar 2008 10:27:13 -0300 (ADT)
Received: by wx-out-0506.google.com with SMTP id r21so3037837wxc.28
	for <pgsql-performance@postgresql.org>;
	Tue, 25 Mar 2008 06:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=l9pydlXiVWBnpzBSmM40cHP16ZdpQKb9Pgw+7mQsPDY=;
	b=UfxmESCISwDcmnEQdfWVcfAlejyTsYU5MH329dpykLVBM9p+YvHfk0xE/h86SwGDjQY3BbSCoMuWf18RhvC378zel+BJUjG+2QBLZ6gDO+xEWkn8CbJmrN9kdosidgitD4Z7dT9wGr/eceEu9eAXRiS+v0/5V9GrcikjlyvjnqA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=Q9yOqEsNUjrSAbKgiHZHtYhx9YNCpBM0rsi7HFQbWzrnpXre9UtMSdZy0Nqc5jnIw62wb6oCVkQ3+69DTCqS/7yX4cwpzKRDgNQez/Ova/NV252rYE0fEaxJCv0lQrnbdq2kRNal0bRnKoejYt2C50w2bNzAofp1d2mjkVF7x2c=
Received: by 10.100.198.20 with SMTP id v20mr278173anf.118.1206451632597;
	Tue, 25 Mar 2008 06:27:12 -0700 (PDT)
Received: by 10.100.105.20 with HTTP; Tue, 25 Mar 2008 06:27:12 -0700 (PDT)
Message-ID: <f966c2ee0803250627gdd5f1eai61b0bbb199320fd3@mail.gmail.com>
Date: Tue, 25 Mar 2008 18:57:12 +0530
From: "sathiya psql" <sathiya.psql@gmail.com>
To: "Bill Moran" <wmoran@collaborativefusion.com>
Subject: Re: postgresql is slow with larger table even it is in RAM
Cc: pgsql-performance@postgresql.org
In-Reply-To: <20080325091046.b5d50a35.wmoran@collaborativefusion.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3233_7781683.1206451632573"
References: <f966c2ee0803250135h57ba1d5bs41f77616ae7186dc@mail.gmail.com>
	<20080325091046.b5d50a35.wmoran@collaborativefusion.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200803/474
X-Sequence-Number: 29428

------=_Part_3233_7781683.1206451632573
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
> 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

>
> 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

>
>
are you saying it will take 3 seconds surely if i have 50 lakh record

------=_Part_3233_7781683.1206451632573
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes. &nbsp;It takes your hardware about 3 seconds to read through 700M of ram.<br>

</blockquote><div><br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Keep in mind that you&#39;re not just reading RAM. &nbsp;You&#39;re pushing system<br>
requests through the VFS layer of your operating system, which is treating<br>
the RAM like a disk (with cylinder groups and inodes and blocks, etc) so<br>
you have all that processing overhead as well. &nbsp;What filesystem did you<br>
format the RAM disk with?<br>
</blockquote><div>tmpfs <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Why are you doing this? &nbsp;If you have enough RAM to store the table, why<br>
not just allocate it to shared buffers?</blockquote><div><br>just allocating will&nbsp; make read from hdd to RAM at first time, to eliminate that <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
</blockquote></div><br>are you saying it will take 3 seconds surely if i have 50 lakh record<br>

------=_Part_3233_7781683.1206451632573--