Re: BRIN indexes - TRAP: BadArgument

Greg Stark wrote:

> 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.

Hm, I guess this could use some expansion.

> 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?

I think I already replied to this in the other email.

> 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.

Every time the index is accessed, yeah. I'm not sure about figuring the
initial creation details. Do you think we need another support
procedure to help with that? We can add it if needed; minmax would just
define it to InvalidOid.

> 4) It doesn't look like BRIN handles cross-type operators at all.

The idea here is that there is a separate opclass to handle cross-type
operators, which would be together in the same opfamily as the opclass
used to create the index. I haven't actually tried this yet, mind you.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services