Re: Minmax indexes

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Minmax indexes
Дата
Msg-id 53E4CEED.2060804@vmware.com
обсуждение исходный текст
Ответ на Re: Minmax indexes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы BRIN indexes (was Re: Minmax indexes)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Another race condition:

If a new tuple is inserted to the range while summarization runs, it's 
possible that the new tuple isn't included in the tuple that the 
summarization calculated, nor does the insertion itself udpate it.

1. There is no index tuple for page range 1-10
2. Summarization begins. It scans pages 1-5.
3. A new insertion inserts a heap tuple to page 1.
4. The insertion sees that there is no index tuple covering range 1-10, 
so it doesn't update it.
5. The summarization finishes scanning pages 5-10, and inserts the new 
index tuple. The summarization didn't see the newly inserted heap tuple, 
and hence it's not included in the calculated index tuple.

One idea is to do the summarization in two stages. First, insert a 
placeholder tuple, with no real value in it. A query considers the 
placeholder tuple the same as a missing tuple, ie. always considers it a 
match. An insertion updates the placeholder tuple with the value 
inserted, as if it was a regular mmtuple. After summarization has 
finished scanning the page range, it turns the placeholder tuple into a 
regular tuple, by unioning the placeholder value with the value formed 
by scanning the heap.

- Heikki




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

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: pgcrypto: PGP armor headers
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: A worst case for qsort