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-05T00:37:54Z
Lists: pgsql-hackers

Attachments

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).


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?


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