Re: WIP: BRIN multi-range indexes

Minor fix, adding the bsearch_arg to Mkvcbuild.pm (per cfbot failure).

regards

On 3/8/21 1:53 AM, Tomas Vondra wrote:
> Hi,
>
> Here is a slightly improved patch series, fixing a lot of wording issues
> and typos (thanks to Justin Pryzby). I also realized create_index.sgml
> is not the right place to document opclass parameters - that worked when
> the parameters were speficified in WITH, but that's no longer the case.
>
> So I've moved this bit to brin.sgml, under the table listing opclasses.
>
> On 3/5/21 1:37 AM, Tomas Vondra wrote:
>> Hi,
>>
>> Here is an updated version of the patch series, with a couple minor
>> changes/improvements.
>>
>> 1) adding bsearch_arg to src/port/
>>
>> 2) moving minmax/inclusion changes from 0002 to a separate patch 0003
>>
>> I think we should either ditch the 0003 (i.e. keep the existing
>> opclasses unchanged) or commit 0003 (in which case I'd vote to just stop
>> supporting the old signature of the consistent function).
>>
>
> Still not sure what do to about this. I'm leaning towards keeping 0003
> and just removing the "old" signature entirely, to keep the API cleaner.
> It might cause some breakage in out-of-core BRIN opclasses, but that
> seems like a reasonable price. Moreover, the opclasses may need some
> updating anyway, because of the changes in handling NULL scan keys (0004
> moves that from the opclass to the bringetbitmap function).
>
>>
>> The remaining part that didn't get much review is the very last patch,
>> adding an option to ignore correlation for some BRIN opclases. This is
>> needed as the regular BRIN costing is quite sensitive to correlation,
>> and the cost gets way too high for poorly correlated data, making it
>> unlikely the index will be used. But handling such data sets efficiently
>> is the main point of those new opclasses. Any opinions on this?
>>
>
> Not sure about this.
>
>
> regards
>

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company