Re: BRIN indexes - TRAP: BadArgument

Greg Stark wrote:

> There's another API question I have. To implement Consistent I need to
> call the hash function which in the case of functions like hashtext
> could be fairly expensive and I even need to generate multiple hash
> values(though currently I'm slicing them all from the integer hash
> value so that's not too bad) and then test each of those bits. It
> would be natural to call hashtext once at the start of the scan and
> possibly build a bitmap and compare all of them in a single &
> operation. But afaict there's no way to hook the beginning of the scan
> and opaque is not associated with the specific scan so I don't think I
> can cache the hash value of the scan key there safely. Is there a good
> way to do it with the current API?

I'm not sure why you say opaque is not associated with the specific
scan.  Are you thinking we could reuse opaque for a future scan?  I
think we could consider that opaque *is* the place to cache things such
as the hashed value of the qual constants or whatever.

> On a side note I'm curious about something, I was stepping through the
> my code in gdb and discovered that a single row insert appeared to
> construct a new summary then union it into the existing summary
> instead of just calling AddValue on the existing summary. Is that
> intentional? What led to that?

That's to test the Union procedure; if you look at the code, it's just
used in assert-enabled builds.  Now that I think about it, perhaps this
can turn out to be problematic for your bloom filter opclass.  I
considered the idea of allowing the opclass to disable this testing
procedure, but it isn't done (yet.)

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