Re: Minmax indexes - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Minmax indexes
Date
Msg-id 53E4CEED.2060804@vmware.com
Whole thread Raw
In response to Re: Minmax indexes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses BRIN indexes (was Re: Minmax indexes)
List 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 by date:

Previous
From: Marko Tiikkaja
Date:
Subject: pgcrypto: PGP armor headers
Next
From: Stephen Frost
Date:
Subject: Re: A worst case for qsort