Re: BRIN INDEX value

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: BRIN INDEX value
Дата
Msg-id 55E922D4.9080607@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: BRIN INDEX value  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: BRIN INDEX value  (Tatsuo Ishii <ishii@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: BRIN INDEX value
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: BRIN INDEX value