Re: BRIN INDEX value - Mailing list pgsql-hackers

From Amit Langote
Subject Re: BRIN INDEX value
Date
Msg-id 55E922D4.9080607@lab.ntt.co.jp
Whole thread Raw
In response to Re: BRIN INDEX value  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: BRIN INDEX value  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
On 9/4/2015 1:33 PM, Tatsuo Ishii wrote:
>> 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?

One thing I imagine we could do is to change the signature of
summrize_range() to also include heapNumBlks which its (only) caller
brinsummarize() already computes. It will look like:

static void summarize_range(IndexInfo *indexInfo, BrinBuildState *state,                             Relation heapRel,
                          BlockNumber heapBlk,                             BlockNumber heapNumBlks);
 

I'd think changing summarize_range()'s signature would be relatively
easier/safer.

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: BRIN INDEX value
Next
From: Tatsuo Ishii
Date:
Subject: Re: BRIN INDEX value