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-08T12:50:28Z
Lists: pgsql-hackers

Attachments

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

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