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-04 04:33:31 |
Message-ID: | 20150904.133331.812720785342174084.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 9/4/2015 8:28 AM, Tatsuo Ishii wrote:
>>>
>>> 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?
>>
>
> Ah, it did cross my mind to the fix it in brin.c but was not sure. I did
> it that way in the attached patch.
Amit,
I have looked into your patch and am a little bit worried because it
calls RelationGetNumberOfBlocks() which is an expensive function.
I think there are two ways to avoid it.
1) fall back to your former patch. However it may break existing
behavior what you said. I think there's very little chance it
actually happens because IndexBuildHeapRangeScan() is only used by
brin (I confirmed this). But Alvaro said some patches may be it's
customers. Robert, Amit, Can you please confirm this?
2) change the signature of IndexBuildHeapRangeScan() to be able to
teach it to limit the target block number to not exceed the last
page of the relation. Again this may break someone's patch and need
confirmation.
What do you think?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-09-04 04:49:24 | Re: BRIN INDEX value |
Previous Message | Pavel Stehule | 2015-09-04 04:24:42 | Re: proposal: function parse_ident |