From: Vitalii Tymchyshyn <tivv00@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Slow count(*) again...
Date: Wed, 13 Oct 2010 13:41:52 +0300
Message-ID: <4CB58CF0.4020601@gmail.com> (raw)
In-Reply-To: <4CB44A3B.5090409@postnewspapers.com.au>
References: <201010091626.18636.neil.whelchel@gmail.com>
<AANLkTimayTM__hHu9RoiLaNhzfpNY6Vo5y4OkbX_sV=o@mail.gmail.com>
<4CB34D69.6060108@emolecules.com>
<4CB4149D.8030803@gmail.com>
<4CB41902.1020503@postnewspapers.com.au>
<alpine.DEB.2.00.1010120118030.21889@asgard.lang.hm>
<4CB44A3B.5090409@postnewspapers.com.au>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tivv00@gmail.com
Subject: Re: Slow count(*) again...
In-Reply-To: <4CB58CF0.4020601@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox