Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25
Дата
Msg-id 2322240.1686882232@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25  (Alexander Lakhin <exclusion@gmail.com>)
Список pgsql-bugs
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> It seems that the minimum false positive rate also doesn't work:

> postgres(1:3419179)=# create table t (a int);
> CREATE TABLE
> postgres(1:3419179)=# create index t_idx on t using brin (a
> int4_bloom_ops (false_positive_rate = 0.0001));
> CREATE INDEX
> postgres(1:3419179)=# insert into t values (1);
> 2023-06-16 11:14:01.349 JST [3419179] ERROR:  the bloom filter is too
> large (8924 > 8144)
> 2023-06-16 11:14:01.349 JST [3419179] STATEMENT:  insert into t values (1);
> ERROR:  the bloom filter is too large (8924 > 8144)

Hmm, but it would work with a larger page size, right?  If so
I'm disinclined to move the minimum.  What I don't like about
the above is that the failure doesn't occur until you actually
insert an index entry.  Is there a way to check for this at
CREATE INDEX time?

            regards, tom lane



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_dump assertion failure with "-n pg_catalog"