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>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, 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>
Subject: Re: BRIN range operator class
Date: 2015-04-06 21:17:24
Message-ID: 20150406211724.GH4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the updated patch; I will at it as soon as time allows. (Not
really all that soon, regrettably.)

Judging from a quick look, I think patches 1 and 5 can be committed
quickly; they imply no changes to other parts of BRIN. (Not sure why 1
and 5 are separate. Any reason for this?) Also patch 2.

Patch 4 looks like a simple bugfix (or maybe a generalization) of BRIN
framework code; should also be committable right away. Needs a closer
look of course.

Patch 3 is a problem. That code is there because the union proc is only
used in a corner case in Minmax, so if we remove it, user-written Union
procs are very likely to remain buggy for long. If you have a better
idea to test Union in Minmax, or some other way to turn that stuff off
for the range stuff, I'm all ears. Just lets make sure the support
procs are tested to avoid stupid bugs. Before I introduced that, my
Minmax Union proc was all wrong.

Patch 7 I don't understand. Will have to look closer. Are you saying
Minmax will depend on Btree opclasses? I remember thinking in doing it
that way at some point, but wasn't convinced for some reason.

Patch 6 seems the real meat of your own stuff. I think there should be
a patch 8 also but it's not attached ... ??

--
Á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 Greg Stark 2015-04-06 22:18:50 Re: Freeze avoidance of very large table.
Previous Message Alvaro Herrera 2015-04-06 21:03:57 Re: Auditing extension for PostgreSQL (Take 2)