Re: BRIN indexes - TRAP: BadArgument

On Sun, Nov 9, 2014 at 5:06 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> I'm trying to do a bloom filter Brin index. I'm already a bit puzzled
> by a few things but I've just started so maybe it'll become clear.

So some quick comments from pretty early goings -- partly because I'm
afraid once I get past them I'll forget what it was I was confused
by....

1) The manual describes the exensibility API including the BrinOpcInfo
struct -- but it doesn't define the BrinDesc struct that every API
method takes. It's not clear what exactly that argument is for or how
to make use of it.

2) The mention about additional opclass operators and to number them
from 11 up is fine -- but there's no explanation of how to decide what
operators need to be explicitly added like that. Specifically I gather
from reading minmax that = is handled internally by Brin and you only
need to add any other operators aside from = ? Is that right?

3) It's not entirely clear in the docs when each method is will be
invoked. Specifically it's not clear whether opcInfo is invoked once
when the index is defined or every time the definition is loaded to be
used. I gather it's the latter? Perhaps there needs to be a method
that's invoked specifically when the index is defined? I'm wondering
where I'm going to hook in the logic to determine the size and number
of hash functions to use for the bloom filter which needs to be
decided once when the index is created and then static for the index
in the future.

4) It doesn't look like BRIN handles cross-type operators at all. For
example this query with btree indexes can use the index just fine
because it looks up the operator based on both the left and right
operands:

::***# explain select * from data where i = 1::smallint;
┌─────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├─────────────────────────────────────────────────────────────────────┤
│ Index Scan using btree_i on data (cost=0.42..8.44 rows=1 width=14) │
│ Index Cond: (i = 1::smallint) │
└─────────────────────────────────────────────────────────────────────┘
(2 rows)

But Minmax opclasses don't contain the cross-type operators and in
fact looking at the code I don't think minmax would be able to cope
(minmax_get_procinfo doesn't even get passed the type int he qual,
only the type of the column).

::***# explain select * from data2 where i = 1::smallint;
┌──────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├──────────────────────────────────────────────────────────┤
│ Seq Scan on data2 (cost=0.00..18179.00 rows=1 width=14) │
│ Filter: (i = 1::smallint) │
└──────────────────────────────────────────────────────────┘
(2 rows)

Time: 0.544 ms

--
greg