Re: BRIN minmax multi - incorrect distance for infinite timestamp/date

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Дата
Msg-id CAEZATCVquhefWxc56AW0wtN2_ztXn85qPs5sEOptFDD-p+nxCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BRIN minmax multi - incorrect distance for infinite timestamp/date  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: BRIN minmax multi - incorrect distance for infinite timestamp/date  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
On Thu, 19 Oct 2023, 05:32 Ashutosh Bapat, <ashutosh.bapat.oss@gmail.com> wrote:
On Wed, Oct 18, 2023 at 8:23 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:

>
> I did use that many values to actually force "compaction" and merging of
> points into ranges. We only keep 32 values per page range, so with 2
> values we'll not build a range. You're right it may still trigger the
> overflow (we probably still calculate distances, I didn't realize that),
> but without the compaction we can't check the query plans.
>
> However, I agree 60 values may be a bit too much. And I realized we can
> reduce the count quite a bit by using the values_per_range option. We
> could set it to 8 (which is the minimum).
>

I haven't read BRIN code, except the comments in the beginning of the
file. From what you describe it seems we will store first 32 values as
is, but later as the number of values grow create ranges from those?
Please point me to the relevant source code/documentation. Anyway, if
we can reduce the number of rows we insert, that will be good.

I don't think 60 values is excessive, but instead of listing them out by hand, perhaps use generate_series().

Regards,
Dean

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: pgsql: Generate automatically code and documentation related to wait ev