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