Re: WIP: BRIN multi-range indexes
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: John Naylor <john.naylor@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-12T16:13:03Z
Lists: pgsql-hackers
Attachments
On Fri, Sep 11, 2020 at 03:19:58PM -0400, John Naylor wrote: >On Fri, Sep 11, 2020 at 2:05 PM Tomas Vondra ><tomas.vondra@2ndquadrant.com> wrote: >> that bad. But yeah, testing and benchmarking it would be nice. Do you >> plan to test just the minmax-multi opclass, or will you look at the >> bloom one too? > >Yeah, I'll start looking at bloom next week, and I'll include it when >I do perf testing. > OK. Here is a slightly improved version of the patch series, with better commit messages and comments, and with the two patches tweaking handling of NULL values merged into one. As mentioned in my reply to Alvaro, I'm hoping to get the first two parts (general improvements) committed soon, so that we can focus on the new opclasses. I now recall why I was postponing pushing those parts because it's primarily "just" a preparation for the new opclasses. Both the scan keys and NULL handling tweaks are not going to help existing opclasses very much, I think. The NULL-handling might help a bit, but the scan key changes are mostly irrelevant. So I'm wondering if we should even change the two existing opclasses, instead of keeping them as they are (the code actually supports that by checking number of arguments of the constitent function). Opinions? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
BRIN minmax-multi indexes
- ab596105b55f 14.0 landed
-
BRIN bloom indexes
- 77b88cd1bb90 14.0 landed
-
Support the old signature of BRIN consistent function
- a681e3c107aa 14.0 landed
-
Remove unnecessary pg_amproc BRIN minmax entries
- a68dfa27d42f 14.0 landed
-
Optimize allocations in bringetbitmap
- 8e4b332e88b8 14.0 landed
-
Move IS [NOT] NULL handling from BRIN support functions
- 72ccf55cb99c 14.0 landed
-
Pass all scan keys to BRIN consistent function at once
- a1c649d889bd 14.0 landed
-
Properly detoast data in brin_form_tuple
- d2d3a4bd33d2 9.5.24 landed
- bae31e75f777 9.6.20 landed
- 0b96fc977c5b 10.15 landed
- 895d0f0e8218 11.10 landed
- 8149e9f9a0d6 12.5 landed
- 6a7b55f3716f 13.1 landed
- 7577dd84807a 14.0 landed