| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP: BRIN multi-range indexes |
| Date: | 2019-03-02 09:05:34 |
| Message-ID: | CAPpHfdsUSu+tEo6Kaj_iXvrhzhGOZ2pkYEn_aWj9b4M2vHGEhg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 4, 2018 at 3:15 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> I've been thinking about this after looking at 0a459cec96, and I don't
> think this patch has the same issues. One reason is that just like the
> original minmax opclass, it does not really mess with the data it
> stores. It only does min/max on the values, and stores that, so if there
> was NaN or Infinity, it will index NaN or Infinity.
FWIW, I think the closest similar functionality is subtype_diff
function of range type. But I don't think we should require range
type here just in order to fetch subtype_diff function out of it. So,
opclass distance function looks OK for me, assuming it's not
AM-defined function, but function used for inter-opclass
compatibility.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2019-03-02 09:09:44 | RE: Timeout parameters |
| Previous Message | Alexander Korotkov | 2019-03-02 09:00:10 | Re: WIP: BRIN multi-range indexes |