Re: WIP: BRIN multi-range indexes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: WIP: BRIN multi-range indexes
Date
Msg-id bb3d9479-b8f7-a1be-587d-830f4d41b047@2ndquadrant.com
Whole thread Raw
In response to Re: WIP: BRIN multi-range indexes  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: WIP: BRIN multi-range indexes
List pgsql-hackers

On 3/13/19 9:15 AM, Alexander Korotkov wrote:
> On Tue, Mar 12, 2019 at 8:15 PM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>>> 0001. Pass all keys to BRIN consistent function at once.
>>>
>>> I think that changing the signature of consistent function is bad, because then
>>> the authors of existing BRIN opclasses will need to maintain two variants of
>>> the function for different version of PosgreSQL.  Moreover, we can easily
>>> distinguish two variants by the number of parameters.  So I returned back a
>>> call to old 3-argument variant of consistent() in bringetbitmap().  Also I
>>> fixed brinvalidate() adding support for new 4-argument variant, and fixed
>>> catalog entries for brin_minmax_consistent() and brin_inclusion_consistent()
>>> which remained 3-argument.  And also I removed unneeded indentation shift in
>>> these two functions, which makes it difficult to compare changes, by extracting
>>> subroutines minmax_consistent_key() and inclusion_consistent_key().
>>>
>>
>> Hmmm. I admit I rather dislike functions that change the signature based
>> on the number of arguments, for some reason. But maybe it's better than
>> changing the consistent function. Not sure.
> 
> I also kind of dislike signature change based on the number of
> arguments.  But it's still good to let extensions use old interface if
> needed.  What do you think about invention new consistent method, so
> that extension can implement one of them?  We did similar thing for
> GIN (bistate consistent vs tristate consistent).
> 

Possibly. The other annoyance of course is that to support the current
consistent method we'll have to keep all the code I guess :-(

regards

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


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: CPU costs of random_zipfian in pgbench
Next
From: Georgios Kokolatos
Date:
Subject: Re: CPU costs of random_zipfian in pgbench