On 12 October 2011 17:26, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Oct 12, 2011 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.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