From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Emre Hasegeli <emre(at)hasegeli(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: BRIN range operator class |
Date: | 2015-05-12 20:02:36 |
Message-ID: | 20150512200236.GM2523@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> On 05/12/2015 10:49 PM, Alvaro Herrera wrote:
> >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.
>
> A version number in the metapage is a certainly a good idea. But we already
> have that, don't we? :
>
> >/* Metapage definitions */
> >typedef struct BrinMetaPageData
> >{
> > uint32 brinMagic;
> > uint32 brinVersion;
> > BlockNumber pagesPerRange;
> > BlockNumber lastRevmapPage;
> >} BrinMetaPageData;
> >
> >#define BRIN_CURRENT_VERSION 1
> >#define BRIN_META_MAGIC 0xA8109CFA
>
> Did you have something else in mind?
Yeah, I was thinking we could have a separate version number for the
opclass code as well. An external extension could change that, for
instance. Also, we could change the 'inclusion' version and leave
minmax alone.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-12 21:22:17 | Re: EvalPlanQual behaves oddly for FDW queries involving system columns |
Previous Message | Heikki Linnakangas | 2015-05-12 19:54:24 | Re: BRIN range operator class |