Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Bruce Momjian wrote:
> >>>> Also, I am wondering whether the information that which index is used to
> >>>> fetch a tuple is always available. I haven't checked, but do we have that
> >>>> information in lossy bitmap heapscan ?
> >>> Oh, that is an interesting problem because an index might have one index
> >>> entry representing an entire HOT chain, while another index might
> >>> represent each chain member by individual index entries. When we do the
> >>> bitmaps, don't we access them by heap tid, meaning we would find all
> >>> entries anyway?
> >> I thinking some more, it would be a problem because while we are merging
> >> the tids, we are using index entries and haven't looked at the heap yet.
> >> I am guessing we would have to exclude the new index from bitmap joins
> >> with other indexes until the VACUUM happens.
> >
> > Thinking some more, bitmap scans have a mode that tracks just the page
> > numbers, rather than the tids --- if the index visibilities do not
> > match, we would need to fall back to that mode.
>
> You don't need to scan the whole page like in the lossy bitmap mode,
> just all the tuples in the HOT-chain.
>
> You need to somehow pass the information that multiple indexes have been
> used in the bitmap scan to the bitmap heapscan node, so that it knows
> when the extra checking is required.
That might be confusing because you are going to have some tids that are
chains, and some that aren't. The hard part is making sure you don't
include the same tid twice.
Another idea is to set pg_index xid to FrozenTransactionId once the
VACUUM happens, and if it not frozen, do something special for bitmap
scans.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
