Message-ID: <4428296B.9040505@i-logic.hu>
Date: Mon, 27 Mar 2006 20:05:31 +0200
From: =?ISO-8859-1?Q?G=E1briel_=C1kos?= <akos.gabriel@i-logic.hu>
Organization: I-Logic Kft
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: count(*) performance
References: <4427E9E8.9030806@i-logic.hu>
	<20060327134103.GI80726@pervasive.com>
In-Reply-To: <20060327134103.GI80726@pervasive.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jim C. Nasby wrote:

> But in this case, I'd bet money that if it's taking 4 minutes something
> else is wrong. Have you been vacuuming that table frequently enough?

That gave me an idea. I thought that autovacuum is doing it right, but I
issued a vacuum full analyze verbose , and it worked all the day.
After that I've tweaked memory settings a bit too (more fsm_pages)

Now:

staging=# SELECT count(*) from infx.infx_product;
   count
---------
  3284997
(1 row)

Time: 1301.049 ms

As I saw the output, the database was compressed to 10% of its size :)
This table has quite big changes every 4 hour, let's see how it works.
Maybe I'll have to issue full vacuums from cron regularly.

> What's SELECT relpages FROM pg_class WHERE relname='tablename' show?

This went to 10% as well, now it's around 156000 pages.

Regards,
Akos


-- 
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.gabriel@i-logic.hu|Web:  http://www.i-logic.hu=-
-=Tel/fax:+3612367353            |Mobil:+36209278894            =-