Re: WIP: BRIN multi-range indexes

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