Horton

Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-06-08T12:03:47Z
Lists: pgsql-hackers

Attachments

Here's a rebased version of this patch series, no other changes.

On 2/25/23 12:45, Tomas Vondra wrote:
> On 2/24/23 22:07, Heikki Linnakangas wrote:
>> I had a quick look at just the preliminary cleanup patches:
>>
>>> 0001-BRIN-bloom-cleanup-20230218.patch
>>
>> Looks good to me
>>
>>> 0002-BRIN-minmax-multi-cleanup-20230218.patch
>>
>> Looks good, although it would feel more natural to me to do it the other
>> way round, and define 'matches' as 'bool matches', and use DatumGetBool.
>>
> 
> Yeah, probably. I was trying to only do the minimal change because of
> (maybe) backpatching this.
> 

I haven't changed this.

Heikki, do you think these cleanup parts should be backpatched? If yes,
do you still think it should be reworked to do it the other way, or like
I did it do minimize the change?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Improve BRIN minmax-multi opclass test coverage

  2. Introduce bloom_filter_size for BRIN bloom opclass

  3. Minor cleanups in the BRIN code

  4. Support GiST index support functions that want to cache data across calls.