Re: WIP: BRIN multi-range indexes

From: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: BRIN multi-range indexes
Date: 2019-03-12 10:33:55
Message-ID: 49cb668f-d6f9-3493-681d-7d40b715ef64@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi!

I have looked at this patch set too, but so far only at first two
infrastructure patches.

First of all, I agree that opclass parameters patch is needed here.

0001. Pass all keys to BRIN consistent function at once.

I think that changing the signature of consistent function is bad, because then
the authors of existing BRIN opclasses will need to maintain two variants of
the function for different version of PosgreSQL. Moreover, we can easily
distinguish two variants by the number of parameters. So I returned back a
call to old 3-argument variant of consistent() in bringetbitmap(). Also I
fixed brinvalidate() adding support for new 4-argument variant, and fixed
catalog entries for brin_minmax_consistent() and brin_inclusion_consistent()
which remained 3-argument. And also I removed unneeded indentation shift in
these two functions, which makes it difficult to compare changes, by extracting
subroutines minmax_consistent_key() and inclusion_consistent_key().

0002. Move IS NOT NULL checks to bringetbitmap()

I believe that removing duplicate code is always good. But in this case it
seems a bit inconsistent to refactor only bringetbitmap(). I think we can't
guarantee that existing opclasses work with null flags in add_value() and
union() in the expected way.

So I refactored the work with BrinValues flags in other places in patch 0003.
I added flag BrinOpcInfp.oi_regular_nulls which enables regular processing of
NULLs before calling of support functions. Now support functions don't need to
care about bv_hasnulls at all. add_value(), for example, works now only with
non-NULL values.

Patches 0002 and 0003 should be merged, I put 0003 in a separate patch just
for ease of review.

0004. BRIN bloom indexes
0005. BRIN multi-range minmax indexes

I have not looked carefully at these packs yet, but fixed only catalog entries
and removed NULLs processing according to patch 0003. I also noticed that the
following functions contain a lot of duplicated code, which needs to be
extracted into common subroutine:
inclusion_get_procinfo()
bloom_get_procinfo()
minmax_multi_get_procinfo()

Attached patches with all my changes.

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
0001-Pass-all-keys-to-BRIN-consistent-function-at-once-20190312.patch.gz application/gzip 4.6 KB
0002-Move-IS-NOT-NULL-checks-to-bringetbitmap-20190312.patch.gz application/gzip 3.0 KB
0003-Move-processing-of-NULLs-from-BRIN-support-functions-20190312.patch.gz application/gzip 4.5 KB
0004-BRIN-bloom-indexes-20190312.patch.gz application/gzip 20.3 KB
0005-BRIN-multi-range-minmax-indexes-20190312.patch.gz application/gzip 29.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Georgios Kokolatos 2019-03-12 11:02:44 Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint
Previous Message MikalaiKeida 2019-03-12 10:27:10 RE: Timeout parameters