From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: BRIN multi-range indexes
Date: Tue, 4 Aug 2020 17:17:43 +0200
Message-ID: <20200804151743.dbobvzovtnpgfpn7@development> (raw)
In-Reply-To: <CAPpHfdt0YW-+-HzWPmwxCrQBsuc1J+VOOdzg0akuP_XYoxk_cA@mail.gmail.com>
References: <20200713001419.te5aozy7o76ff2vk@development>
<20200713003310.GA22495@alvherre.pgsql>
<CA+fd4k6S2ns4uHhT+ym3+A8ry7Dz8GQ4tk-t4WgCpSoEyt3RiQ@mail.gmail.com>
<20200713145850.5skhxmqezswz2ovl@development>
<CAPpHfdt_d2OtUB4zaobtkD82Xm6BSCXU7RCj5LnHt4yOF0S9sg@mail.gmail.com>
<20200719151945.p6iaexethuplxxic@development>
<CAPpHfdt0YW-+-HzWPmwxCrQBsuc1J+VOOdzg0akuP_XYoxk_cA@mail.gmail.com>
On Tue, Aug 04, 2020 at 05:36:51PM +0300, Alexander Korotkov wrote:
>Hi, Tomas!
>
>Sorry for the late reply.
>
>On Sun, Jul 19, 2020 at 6:19 PM Tomas Vondra
><tomas.vondra@2ndquadrant.com> wrote:
>> I think there's a number of weak points in this approach.
>>
>> Firstly, it assumes the summaries can be represented as arrays of
>> built-in types, which I'm not really sure about. It clearly is not true
>> for the bloom opclasses, for example. But even for minmax oclasses it's
>> going to be tricky because the ranges may be on different data types so
>> presumably we'd need somewhat nested data structure.
>>
>> Moreover, multi-minmax summary contains either points or intervals,
>> which requires additional fields/flags to indicate that. That further
>> complicates the things ...
>>
>> maybe we could decompose that into separate arrays or something, but
>> honestly it seems somewhat premature - there are far more important
>> aspects to discuss, I think (e.g. how the ranges are built/merged in
>> multi-minmax, or whether bloom opclasses are useful at all).
>
>I see. But there is at least a second option to introduce a new
>datatype with just an output function. In the similar way
>gist/tsvector_ops uses gtsvector key type. I think it would be more
>transparent than using just bytea. Also, this is the way we already
>use in the core.
>
So you're proposing to have a new data types "brin_minmax_multi_summary"
and "brin_bloom_summary" (or some other names), with output functions
printing something nicer? I suppose that could work, and we could even
add pageinspect functions returning the value as raw bytea.
Good idea!
>> >BTW, I've applied the patchset to the current master, but I got a lot
>> >of duplicate oids. Could you please resolve these conflicts. I think
>> >it would be good to use high oid numbers to evade conflicts during
>> >development/review, and rely on committer to set final oids (as
>> >discussed in [1]).
>> >
>> >Links
>> >1. https://www.postgresql.org/message-id/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-%3DeaochT0dd2BN9CQ%40mail.g...
>>
>> Did you use the patchset from 2020/07/03? I don't get any duplicate OIDs
>> with it, and it's already using quite high OIDs (part 4 uses >= 8000,
>> part 5 uses >= 9000).
>
>Yep, it appears that I was using the wrong version of patchset.
>Patchset from 2020/07/03 works good on the current master.
>
OK, good.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, aekorotkov@gmail.com, masahiko.sawada@2ndquadrant.com, alvherre@2ndquadrant.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, andres@anarazel.de, hornschnorter@gmail.com
Subject: Re: WIP: BRIN multi-range indexes
In-Reply-To: <20200804151743.dbobvzovtnpgfpn7@development>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox