Horton

Re: WIP: BRIN multi-range indexes

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: John Naylor <john.naylor@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-08T00:53:03Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. BRIN minmax-multi indexes

  2. BRIN bloom indexes

  3. Support the old signature of BRIN consistent function

  4. Remove unnecessary pg_amproc BRIN minmax entries

  5. Optimize allocations in bringetbitmap

  6. Move IS [NOT] NULL handling from BRIN support functions

  7. Pass all scan keys to BRIN consistent function at once

  8. Properly detoast data in brin_form_tuple