Re: Missing update of all_hasnulls in BRIN opclasses
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Matthias van de Meent <boekewurm+postgres@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2023-03-28T14:30:45Z
Lists: pgsql-hackers
Attachments
- 0001-Fix-handling-of-NULLs-in-BRIN-indexes.patch (text/x-patch) patch 0001
- 0002-Show-empty-ranges-in-brin_page_items.patch (text/x-patch) patch 0002
- 0003-extra-tests.patch (text/x-patch) patch 0003
- stress-test.sh (application/x-shellscript)
Hi, It took me a while but I finally got back to reworking this to use the bt_info bit, as proposed by Alvaro. And it turned out to work great, because (a) it's a tuple-level flag, i.e. the right place, and (b) it does not overload existing flags. This greatly simplified the code in add_values_to_range and (especially) union_tuples, making it much easier to understand, I think. One disadvantage is we are unable to see which ranges are empty in current pageinspect, but 0002 addresses that by adding "empty" column to the brin_page_items() output. That's a matter for master only, though. It's a trivial patch and it makes it easier/possible to test this, so we should consider to squeeze it into PG16. I did quite a bit of testing - the attached 0003 adds extra tests, but I don't propose to get this committed as is - it's rather overkill. Maybe some reduced version of it ... The hardest thing to test is the union_tuples() part, as it requires concurrent operations with "correct" timing. Easy to simulate by breakpoints in GDB, not so much in plain regression/TAP tests. There's also a stress tests, doing a lot of randomized summarizations, etc. Without the fix this failed in maybe 30% of runs, now I did ~100 runs without a single failure. I haven't done any backporting, but I think it should be simpler than with the earlier approach. I wonder if we need to care about starting to use the previously unused bit - I don't think so, in the worst case we'll just ignore it, but maybe I'm missing something (e.g. when using physical replication). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Show empty BRIN ranges in brin_page_items
- 428c0cae929b 16.0 landed
-
Fix handling of empty ranges and NULLs in BRIN
- 3581cbdcd64f 16.0 landed
- fc7dc728d1a6 11.21 landed
- d78a66d92c73 12.16 landed
- e187693239ad 15.4 landed
- 40d465cafce0 14.9 landed
- 6c512fc6e90d 13.12 landed
-
Fix handling of NULLs when merging BRIN summaries
- b511d7323df6 11.21 landed
- d42ffda685f5 12.16 landed
- 2b1ab28b9dc9 13.12 landed
- 3f1356e5d60a 14.9 landed
- 80f64b90088a 15.4 landed
- 3ec8a3bfb547 16.0 landed
-
Move IS [NOT] NULL handling from BRIN support functions
- 72ccf55cb99c 14.0 cited