Re: BRIN INDEX value - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: BRIN INDEX value
Date
Msg-id 20150904.082819.2011230414800077415.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: BRIN INDEX value  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: BRIN INDEX value  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Jan Wieck
Date:
Subject: Small patch to fix an O(N^2) problem in foreign keys
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace