Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 8AE841337B59 for ; Wed, 13 Oct 2010 07:41:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 55913-06 for ; Wed, 13 Oct 2010 10:41:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f46.google.com (mail-bw0-f46.google.com [209.85.214.46]) by mail.postgresql.org (Postfix) with ESMTP id 19D45133798E for ; Wed, 13 Oct 2010 07:41:45 -0300 (ADT) Received: by bwz15 with SMTP id 15so3067450bwz.19 for ; Wed, 13 Oct 2010 03:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yApCedJmv4xe9UxvXmBaTrY96i1oi46jjobTHORC1Co=; b=jLpvwBpyHdz79QaZl5guxWNNE3D3AjUMeZRZwhmsqTdvjJDRV1dYGuLE7iiT2hnuIE 797FhuTbfQAbeIVo/HTfnxW6ILVYDCbgSvTMM/d5Fyjee87wJDUPUGUqdGZZVyddsOu+ B3FK+kxeYzsvagD9fW+6OvBzqyZd37D0LzQdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=FK4dt/1wiBGWAdjI6HB52N1MiAtsn14bnqRvHU6QVFU5zsoHY7v4sH80g1kzrvmid0 XnP1WMQzXYEsw0RP+RMuCDqlKz+FpuQAwwgZpOyVPqairwFYzodqZAHpbTRtngqvs7wE cnaSVw2uqApneJi7NsC23xHSBPGxMVgyX7piQ= Received: by 10.204.66.197 with SMTP id o5mr3913258bki.136.1286966504782; Wed, 13 Oct 2010 03:41:44 -0700 (PDT) Received: from [10.1.1.57] (skuns.zoral.com.ua [91.193.166.194]) by mx.google.com with ESMTPS id x13sm8413686bki.12.2010.10.13.03.41.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Oct 2010 03:41:42 -0700 (PDT) Message-ID: <4CB58CF0.4020601@gmail.com> Date: Wed, 13 Oct 2010 13:41:52 +0300 From: Vitalii Tymchyshyn User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Slow count(*) again... References: <201010091626.18636.neil.whelchel@gmail.com> <4CB34D69.6060108@emolecules.com> <4CB4149D.8030803@gmail.com> <4CB41902.1020503@postnewspapers.com.au> <4CB44A3B.5090409@postnewspapers.com.au> In-Reply-To: <4CB44A3B.5090409@postnewspapers.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: 201010/203 X-Sequence-Number: 40622 12.10.10 14:44, Craig Ringer написав(ла): > >> in the case where you are doing a count(*) where query and the where is >> on an indexed column, could the search just look at the index + the >> visibility mapping rather than doing an sequential search through the >> table? > > Nope, because the visibility map, which is IIRC only one bit per page, > doesn't record how many tuples there are on the page, or enough > information about them to determine how many of them are visible to > the current transaction*. I'd say it can tell you that your may not recheck given tuple, can't it? You still have to count all index tuples and recheck the ones that are uncertain. Does it work in this way? This can help a lot for wide tuples in table, but with narrow index and mostly read-only data. Best regards, Vitalii Tymchyshyn