Re: Missing update of all_hasnulls in BRIN opclasses - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Missing update of all_hasnulls in BRIN opclasses
Date
Msg-id 8a085e86-2d54-e944-3a8c-7c43fea6647b@enterprisedb.com
Whole thread Raw
In response to Re: Missing update of all_hasnulls in BRIN opclasses  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Missing update of all_hasnulls in BRIN opclasses
List pgsql-hackers
Hi,

here's an improved and cleaned-up version of the fix.

I removed brinbugs.sql from pageinspect, because it seems enough to have
the other tests (I added brinbugs first, before realizing those exist).
This also means meson.build is fine and there are no tests doing CREATE
EXTENSION concurrently etc.

I decided to go with the 0003 approach, which stores summaries for empty
ranges. That seems to be less intrusive (it's more like what we do now),
and works better for tables with a lot of bulk deletes. It means we can
have ranges with allnulls=hasnulls=true, which wasn't the case before,
but I don't see why this should break e.g. custom opclasses (if it does,
it probably means the opclass is wrong).

Finally, I realized union_tuples needs to be tweaked to deal with empty
ranges properly. The changes are fairly limited, though.

I plan to push this into master right at the beginning of January, and
then backpatch a couple days later.

I still feel a bit uneasy about tweaking this, but I don't think there's
a better way than reusing the existing flags.


regards

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

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: add PROCESS_MAIN to VACUUM
Next
From: Thomas Munro
Date:
Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier