Re: CREATE INDEX and HOT - revised design

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: CREATE INDEX and HOT - revised design
Дата
Msg-id 46017F97.2000408@enterprisedb.com
обсуждение исходный текст
Ответ на Re: CREATE INDEX and HOT - revised design  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: CREATE INDEX and HOT - revised design  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: CREATE INDEX and HOT - revised design
Следующее
От: Grzegorz Jaskiewicz
Дата:
Сообщение: Re: [PATCHES] Bitmapscan changes