On 12 October 2011 17:26, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 12, 2011 at 11:59 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
