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-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

In response to

Responses

Browse pgsql-hackers by date

  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