Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id D85991337BC4 for ; Sun, 6 Feb 2011 15:19:29 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 22520-02 for ; Sun, 6 Feb 2011 19:19:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 31.mail-out.ovh.net (31.mail-out.ovh.net [213.186.62.10]) by mail.postgresql.org (Postfix) with SMTP id 0BE671337BC2 for ; Sun, 6 Feb 2011 15:19:21 -0400 (AST) Received: (qmail 18842 invoked by uid 503); 6 Feb 2011 19:58:04 -0000 Received: from b7.ovh.net (HELO mail97.ha.ovh.net) (213.186.33.57) by 31.mail-out.ovh.net with SMTP; 6 Feb 2011 19:58:04 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 6 Feb 2011 21:19:19 +0200 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 6 Feb 2011 21:19:18 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: felix , "Scott Marlowe" Cc: sthomas@peak6.com, "pgsql-performance@postgresql.org" Subject: Re: Really really slow select count(*) References: <4D4C138C.7010304@2ndquadrant.com> <4D4C1555.40209@peak6.com> <4D4C2AC3.5020804@peak6.com> Date: Sun, 06 Feb 2011 20:19:17 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Linux) X-Ovh-Tracer-Id: 17597252594067375731 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/259 X-Sequence-Number: 42397 >> I have clustered that table, its still unbelievably slow. > > Did you actually delete the old entries before clustering it? if it's > still got 4G of old sessions or whatever in it, clustering ain't gonna > help. Also, IMHO it is a lot better to store sessions in something like memcached, rather than imposing this rather large load on the main database... PS : if your site has been down for 6 hours, you can TRUNCATE your sessions table...