From: Chris Browne <cbbrowne@acm.org>
Subject: Re: postgresql is slow with larger table even it is in RAM
Date: Tue, 25 Mar 2008 11:02:22 -0400
Organization: cbbrowne Computing Inc
Lines: 29
Message-ID: <603aqe979d.fsf@dba2.int.libertyrms.com>
References: <f966c2ee0803250135h57ba1d5bs41f77616ae7186dc@mail.gmail.com>
	<99f1636c0803250139g321329dbr7c640213e9132583@mail.gmail.com>
	<f966c2ee0803250142hae53ef4mfee4487d1fd052a2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
Cancel-Lock: sha1:64YKuoY7MbA7Xg9oveL6aI+prJE=
To: pgsql-performance@postgresql.org

sathiya.psql@gmail.com ("sathiya psql") writes:
> 					  On Tue, Mar 25, 2008 at 2:09 PM, jose javier parra sanchez <jojapasa@gmail.com> wrote:
>
>
>      						  It's been said zillions of times on the maillist. Using a select
>      						 count(*) in postgres is slow, and probably will be slow for a long
>      						   time. So that function is not a good way to measure perfomance.
>      
>
>
> 							  Yes, but if the data is in HDD then we can say this...
> 									but now the data is in RAM

Even if the data all is in RAM, it will still take some definitely
non-zero time to examine all of the pages, looking for tuples, and
then to determine which of those tuples are visible from the
perspective of your DB connection.

If 500MB of relevant data is sitting on disk, then it will take
whatever time it takes to pull it from disk; if it is in memory, there
is still work to be done...
-- 
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://linuxdatabases.info/info/finances.html
Rules of  the Evil Overlord #76.  "If the hero  runs up to my  roof, I
will not run up after him and  struggle with him in an attempt to push
him  over the  edge. I  will also  not  engage him  at the  edge of  a
cliff. (In the middle of a  rope-bridge over a river of molten lava is
not even worth considering.)" <http://www.eviloverlord.com/>