1
0
mirror of https://github.com/postgres/postgres.git synced 2025-10-24 01:29:19 +03:00

BRIN minmax-multi indexes

Adds BRIN opclasses similar to the existing minmax, except that instead
of summarizing the page range into a single [min,max] range, the summary
consists of multiple ranges and/or points, allowing gaps. This allows
more efficient handling of data with poor correlation to physical
location within the table and/or outlier values, for which the regular
minmax opclassed tend to work poorly.

It's possible to specify the number of values kept for each page range,
either as a single point or an interval boundary.

  CREATE TABLE t (a int);
  CREATE INDEX ON t
   USING brin (a int4_minmax_multi_ops(values_per_range=16));

When building the summary, the values are combined into intervals with
the goal to minimize the "covering" (sum of interval lengths), using a
support procedure computing distance between two values.

Bump catversion, due to various catalog changes.

Author: Tomas Vondra <tomas.vondra@postgresql.org>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru>
Reviewed-by: John Naylor <john.naylor@enterprisedb.com>
Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com
Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
This commit is contained in:
Tomas Vondra
2021-03-26 13:54:29 +01:00
parent 77b88cd1bb
commit ab596105b5
19 changed files with 5286 additions and 26 deletions

View File

@@ -14,6 +14,11 @@
#include "access/brin_internal.h"
#include "access/tupdesc.h"
/*
* The BRIN opclasses may register serialization callback, in case the on-disk
* and in-memory representations differ (e.g. for performance reasons).
*/
typedef void (*brin_serialize_callback_type) (BrinDesc *bdesc, Datum src, Datum *dst);
/*
* A BRIN index stores one index tuple per page range. Each index tuple
@@ -27,6 +32,9 @@ typedef struct BrinValues
bool bv_hasnulls; /* are there any nulls in the page range? */
bool bv_allnulls; /* are all values nulls in the page range? */
Datum *bv_values; /* current accumulated values */
Datum bv_mem_value; /* expanded accumulated values */
MemoryContext bv_context;
brin_serialize_callback_type bv_serialize;
} BrinValues;
/*

View File

@@ -161,18 +161,18 @@ FullTransactionIdAdvance(FullTransactionId *dest)
* development purposes (such as in-progress patches and forks);
* they should not appear in released versions.
*
* OIDs 10000-11999 are reserved for assignment by genbki.pl, for use
* OIDs 10000-12999 are reserved for assignment by genbki.pl, for use
* when the .dat files in src/include/catalog/ do not specify an OID
* for a catalog entry that requires one.
*
* OIDS 12000-16383 are reserved for assignment during initdb
* using the OID generator. (We start the generator at 12000.)
* OIDS 13000-16383 are reserved for assignment during initdb
* using the OID generator. (We start the generator at 13000.)
*
* OIDs beginning at 16384 are assigned from the OID generator
* during normal multiuser operation. (We force the generator up to
* 16384 as soon as we are in normal operation.)
*
* The choices of 8000, 10000 and 12000 are completely arbitrary, and can be
* The choices of 8000, 10000 and 13000 are completely arbitrary, and can be
* moved if we run low on OIDs in any category. Changing the macros below,
* and updating relevant documentation (see bki.sgml and RELEASE_CHANGES),
* should be sufficient to do this. Moving the 16384 boundary between
@@ -186,7 +186,7 @@ FullTransactionIdAdvance(FullTransactionId *dest)
* ----------
*/
#define FirstGenbkiObjectId 10000
#define FirstBootstrapObjectId 12000
#define FirstBootstrapObjectId 13000
#define FirstNormalObjectId 16384
/*