Re: BRIN INDEX value

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BRIN INDEX value
Date: 2015-09-03 23:28:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-09-04 00:10:09 Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace
Previous Message Jan Wieck 2015-09-03 22:42:49 Small patch to fix an O(N^2) problem in foreign keys