Subject: Re: WIP: BRIN multi-range indexes
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
 Mark Dilger <hornschnorter@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <20180123200537.gfx5hxcp5k5hktpe@alvherre.pgsql>
 <821c4c1d-592e-8916-e323-04607b11777e@2ndquadrant.com>
 <c32f9f46-e0ca-0c02-45ec-718dd381f4be@2ndquadrant.com>
 <104E8BB8-35FF-4AA8-9871-6AFF04E4CAF3@gmail.com>
 <0afde2fc-e160-004f-8fe2-c65302ac3760@2ndquadrant.com>
 <22674.1517874015@sss.pgh.pa.us>
 <3e924a4c-6ca0-cc10-aebb-5004fc002800@2ndquadrant.com>
 <c2523129-a970-97f2-4705-a3b65e21b32f@2ndquadrant.com>
 <20180302035538.gkqgtcv6kmn2cklw@alap3.anarazel.de>
 <18526.1519963686@sss.pgh.pa.us>
 <1c1c1ced-1f79-a0ee-e5cd-858ca3eb9d74@2ndquadrant.com>
 <CAPpHfdsUSu+tEo6Kaj_iXvrhzhGOZ2pkYEn_aWj9b4M2vHGEhg@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <acfc8aa3-1cbf-b9de-77ba-556ddd84a094@2ndquadrant.com>
Date: Sat, 2 Mar 2019 22:12:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
 <CAPpHfdsUSu+tEo6Kaj_iXvrhzhGOZ2pkYEn_aWj9b4M2vHGEhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 3/2/19 10:05 AM, Alexander Korotkov wrote:
> On Sun, Mar 4, 2018 at 3:15 AM Tomas Vondra
> <tomas.vondra@2ndquadrant.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,

OK, agreed.

> assuming it's not AM-defined function, but function used for
> inter-opclass compatibility.
> 

I'm not sure I understand what you mean by this. Can you elaborate? Does
the current implementation (i.e. distance function being implemented as
an opclass support procedure) work for you or not?

Thanks for looking at the patch!


cheers

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