Re: BRIN range operator class - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: BRIN range operator class
Date
Msg-id 20150512194920.GK2523@alvh.no-ip.org
Whole thread Raw
In response to Re: BRIN range operator class  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: BRIN range operator class  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
So, in reading these patches, it came to me that we might want to have
pg_upgrade mark indexes invalid if we in the future change the
implementation of some opclass.  For instance, the inclusion opclass
submitted here uses three columns: the indexed value itself, plus two
booleans; each of these booleans is a workaround for some nasty design
decision in the underlying datatypes.

One boolean is "unmergeable": if a block range contains both IPv4 and
IPv6 addresses, we mark it as 'unmergeable' and then every query needs
to visit that block range always.  The other boolean is "contains empty"
and is used for range types: it is set if the empty value is present
somewhere in the block range.

If in the future, for instance, we come up with a way to store the ipv4
plus ipv6 info, we will want to change the page format.  If we add a
page version to the metapage, we can detect the change at pg_upgrade
time and force a reindex of the index.

Thoughts?

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Final Patch for GROUPING SETS
Next
From: Heikki Linnakangas
Date:
Subject: Re: BRIN range operator class