Re: BRIN INDEX value

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BRIN INDEX value
Date: 2015-09-04 04:49:24
Message-ID: 55E922D4.9080607@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2015-09-04 05:04:05 Re: BRIN INDEX value
Previous Message Tatsuo Ishii 2015-09-04 04:33:31 Re: BRIN INDEX value