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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Date: 2023-10-19 07:04:44
Message-ID: CAEZATCVquhefWxc56AW0wtN2_ztXn85qPs5sEOptFDD-p+nxCg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 19 Oct 2023, 05:32 Ashutosh Bapat, <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> On Wed, Oct 18, 2023 at 8:23 PM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2023-10-19 07:38:30 Re: pgsql: Generate automatically code and documentation related to wait ev
Previous Message vignesh C 2023-10-19 06:28:12 Re: [PoC] pg_upgrade: allow to upgrade publisher node