Re: BRIN range operator class

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Emre Hasegeli <emre(at)hasegeli(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN range operator class
Date: 2015-05-05 21:22:22
Message-ID: 20150505212222.GP2523@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Can you please explain what is the purpose of patch 07? I'm not sure I
understand; are we trying to avoid having to add pg_amproc entries for
these operators and instead piggy-back on btree opclass definitions?
Not too much in love with that idea; I see that there is less tedium in
that the brin opclass definition is simpler. One disadvantage is a 3x
increase in the number of syscache lookups to get the function you need,
unless I'm reading things wrong. Maybe this is not performance critical.

Anyway I tried applying it on isolation, and found that it fails the
assertion that tests the "union" support proc in brininsert. That
doesn't seem okay. I mean, it's okay not to run the test for the
inclusion opclasses, but why does it now fail in minmax which was
previously passing? Couldn't figure it out.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-05-05 21:51:41 Re: INSERT ... ON CONFLICT syntax issues
Previous Message Robert Haas 2015-05-05 20:42:40 Re: Proposal : REINDEX xxx VERBOSE