Re: WIP: BRIN multi-range indexes

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: WIP: BRIN multi-range indexes
Date: 2021-02-09 23:15:25
Message-ID: 0e2f18d5-cd6d-764b-3912-512e9c722b8a@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/9/21 3:46 PM, John Naylor wrote:
> On Wed, Feb 3, 2021 at 7:54 PM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com <mailto:tomas(dot)vondra(at)enterprisedb(dot)com>>
> wrote:
> >
> > [v-20210203]
>
> Hi Tomas,
>
> I have some random comments from reading the patch, but haven't gone
> into detail in the newer aspects. I'll do so in the near future.
>
> The cfbot seems to crash on this patch during make check, but it doesn't
> crash for me. I'm not even sure what date that cfbot status is from.
>

Yeah, I noticed that too, and I'm investigating.

I tried running the regression tests on a 32-bit machine (rpi4), which
sometimes uncovers strange failures, and that indeed fails. There are
two or three bugs.

Firstly, the allocation optimization patch does this:

MAXALIGN(sizeof(ScanKey) * scan->numberOfKeys * natts)

instead of

MAXALIGN(sizeof(ScanKey) * scan->numberOfKeys) * natts

and that sometimes produces the wrong result, triggering an assert.

Secondly, there seems to be an issue with cross-type bloom indexes.
Imagine you have an int8 column, with a bloom index on it, and then you
do this:

WHERE column = '122'::int4;

Currently, we end up passing this to the consistent function, which
tries to call hashint8 on the int4 datum - that succeeds on 64 bits
(because both types are byval), but fails on 32-bits (where int8 is
byref, so it fails on int4). Which causes a segfault.

I think I included those cross-type operators as a copy-paste from
minmax indexes, but I see hash indexes don't allow this. And removing
those cross-type rows from pg_amop.dat makes the crashes go away.

It's also possible I simplified the get_strategy_procinfo a bit too
much. I see the minmax variant has subtype, so maybe we could do this
instead (I recall the integer types should have "compatible" results).

There are a couple failues where the index does not produce the right
number of results, though. I haven't investigated that yet. Once I fix
this, I'll post an updated patch - hopefully that'll make cfbot happy.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-02-10 00:51:57 Re: Single transaction in the tablesync worker?
Previous Message Noah Misch 2021-02-09 23:01:55 Re: Tightening up allowed custom GUC names