Re: COUNT(*) and index-only scans

On 12 October 2011 17:26, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 12, 2011 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The place where the decision is actually somewhat hard, IMO, is where
>> you're pulling a small part of the table but significantly more than one
>> row, and the traditional best choice would be a bitmap scan.  Now we
>> have to guess whether possibly avoiding heap fetches is better than
>> batching the fetches, and it doesn't seem open-and-shut to me.
>
> Yes, I agree.
>
> I was actually wondering if there is some way we could make index-only
> scans work for bitmap index scans.  Something like this: If the index
> is covering, then as we retrieve each tuple, we check whether the page
> is all-visible.  If so, we return the data from the index tuple.  If
> not, we save the TID for later.  Then, when we get done scanning the
> index, we go back and fetch all the pages containing saved TIDs in
> ascending block number order.  The trouble is that I think you could
> get in some trouble if you use a TID bitmap here, because if you
> lossify the bitmap then you have to make sure you can't return a tuple
> that you already handled with the index-only approach (imagine that
> the visibility map bit gets cleared partway through the scan).  All in
> all this seems pretty complicated...

So is there a chance of getting bitmap index-only scans?

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company