Re: BRIN indexes - TRAP: BadArgument

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Emanuel Calvo <3manuek(at)esdebian(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN indexes - TRAP: BadArgument
Date: 2014-09-23 19:04:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera wrote:

> Heikki Linnakangas wrote:

> > If you add a new datatype, and define b-tree operators for it, what
> > is required to create a minmax opclass for it? Would it be possible
> > to generalize the functions in brin_minmax.c so that they can be
> > reused for any datatype (with b-tree operators) without writing any
> > new C code? I think we're almost there; the only thing that differs
> > between each data type is the opcinfo function. Let's pass the type
> > OID as argument to the opcinfo function. You could then have just a
> > single minmax_opcinfo function, instead of the macro to generate a
> > separate function for each built-in datatype.
> Yeah, that's how I had that initially. I changed it to what it's now as
> part of a plan to enable building cross-type opclasses, so you could
> have "WHERE int8col=42" without requiring a cast of the constant to type
> int8. This might have been a thinko, because AFAICS it's possible to
> build them with a constant opcinfo as well (I changed several other
> things to support this, as described in a previous email.) I will look
> into this later.

I found out that we don't really throw errors in such cases anymore; we
insert casts instead. Maybe there's a performance argument that it
might be better to use existing cross-type operators than casting, but
justifying this work just turned a lot harder. Here's a patch that
reverts opcinfo into a generic function that receives the type OID.

I will look into adding some testing mechanism for the union support
proc; with that I will just consider the patch ready for commit and will

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
minmax-19a.patch text/x-diff 13.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-09-23 19:05:16 Re: proposal: rounding up time value less than its unit.
Previous Message Gregory Smith 2014-09-23 18:59:48 Re: RLS feature has been committed