| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: WIP: BRIN multi-range indexes |
| Date: | 2021-03-26 13:08:03 |
| Message-ID: | 1da94012-f512-ffc8-dd5e-888d862b662e@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I've pushed both the bloom and minmax-multi indexes today.
Based on the feedback and limitations described before I decided to keep
them in core (i.e. not move them to contrib), but it was very useful
experiment as it uncovered a couple issues - both in existing code, and
in the definition of the new opclasses.
After further thought I've concluded that the decision to ditch the old
signature (in a1c649d889) was probably wrong, so I've added the support
back, per what Alexander originally proposed.
While doing so, I've noticed that the NULL handling may be a few bricks
shy, because with (oi_regular_nulls == false) it should probably keep
passing the NULL scan keys to the consistent function. I'll look into
that and get it fixed.
Thanks everyone who helped with those patches!
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2021-03-26 13:14:41 | Re: Stronger safeguard for archive recovery not to miss data |
| Previous Message | Tomas Vondra | 2021-03-26 12:57:37 | Re: WIP: BRIN multi-range indexes |