From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP: BRIN multi-range indexes |
Date: | 2018-03-02 03:55:38 |
Message-ID: | 20180302035538.gkqgtcv6kmn2cklw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-02-25 01:30:47 +0100, Tomas Vondra wrote:
> Note: Currently, this only works with float8-based data types.
> Supporting additional data types is not a big issue, but will
> require extending the opclass with "subtract" operator (used to
> compute distance between values when merging ranges).
Based on Tom's past stances I'm a bit doubtful he'd be happy with such a
restriction. Note that something similar-ish also has come up in
0a459cec96.
I kinda wonder if there's any way to not have two similar but not equal
types of logic here?
That problem is
resolved here by adding the ability for btree operator classes to provide
an "in_range" support function that defines how to add or subtract the
RANGE offset value. Factoring it this way also allows the operator class
to avoid overflow problems near the ends of the datatype's range, if it
wishes to expend effort on that. (In the committed patch, the integer
opclasses handle that issue, but it did not seem worth the trouble to
avoid overflow failures for datetime types.)
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-03-02 03:57:02 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index |
Previous Message | Alvaro Herrera | 2018-03-02 03:53:38 | Re: zheap: a new storage format for PostgreSQL |