Re: [BUGS] BUG #14155: bloom index error with unlogged table

On May 24, 2016 5:27 PM, "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:
>
> Moving my griping to -hackers only
>
> On Tue, May 24, 2016 at 8:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> digoal(at)126(dot)com writes:
>> > postgres=# create unlogged table u_tbl (id int);
>> > CREATE TABLE
>> > postgres=# create index idx_u_tbl on u_tbl using bloom (id);
>> > ERROR: index "idx_u_tbl" already contains data
>>
>> Yeah, it looks like nobody ever tested bloom's unlogged-index support;
>> it doesn't work or even come very close to working. Will fix, thanks
>> for the report!
>
>
> ​I'll tack on my own gripe here, just because.
>
> It doesn't give me a lot of confidence in what was committed when the
summary sentence for the module says:
>
> "
> bloom is a module which implements an index access method. It comes as an
example of custom access methods and generic WAL records usage. But it is
also useful in itself.
> ​"​
>
>
> ​Honestly, as a user I couldn't care less that bloom is "an example
custom access method"​. I want to know what it does and that it does so
reliably, and has a easy-to-use interface. I complained earlier about its
lack of direct support for the boolean type. Teodor's response on the
thread wasn't particularly encouraging:
>

Given what a Bloom filter is/does, I'm having a hard time seeing how it
makes much sense to support the boolean type.

My biggest gripe with it at the moment is that the signature size should be
expressed in bits, and then internally rounded up to a multiple of 16,
rather than having it be expressed in 'uint16'.

If that were done it would be easier to fix the documentation to be more
understandable.

On the positive side, I've done extensive crash-recovery testing (not with
unlogged tables, obviously) and that part seems solid.

Cheers,

Jeff