Re: BRIN INDEX value
От | Tatsuo Ishii |
---|---|
Тема | Re: BRIN INDEX value |
Дата | |
Msg-id | 20150904.082819.2011230414800077415.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: BRIN INDEX value (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: BRIN INDEX value
|
Список | pgsql-hackers |
> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is > passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks >> heapTotalBlocks, further down the line, heapgettup() may start returning > tuples from the beginning given the following code in it: > > page++; > if (page >= scan->rs_nblocks) > page = 0; > > finished = (page == scan->rs_startblock) || > (scan->rs_numblocks != InvalidBlockNumber ? > --scan->rs_numblocks == 0 : > false); > > Where finished indicates whether it thinks the end of heap is reached. > > In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan() > using heap_setscanlimits(). One can imagine how the above heap finish > criteria might not work as expected. > > That helps explain why 1 becomes the min for that brin tuple. > > Attached hack fixes the symptom but perhaps not the correct fix for this. Why can't we fix summarize_range() in brin.c: IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true, heapBlk, state->bs_pagesPerRange, brinbuildCallback, (void *) state); This currently thoughtlessly passes scannumblocks as state->bs_pagesPerRange. Shouldn't we change this so that (scanStartBlock + scanNumBlocks) does not exceed scan->rs_nblocks? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: