From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP: BRIN multi-range indexes |
Date: | 2021-03-03 00:17:25 |
Message-ID: | 20210303001725.GA1766@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Mar-03, Tomas Vondra wrote:
> That's kinda my point - I agree the size of the patch is not the primary
> concern, but it makes the minmax/inclusion code a bit more complicated
> (because they now have to loop over the keys), with very little benefit
> (there might be some speedup, but IMO it's rather negligible).
Yeah, OK.
> Alternatively we could simply remove the code supporting the old API
> with "consistent" functions without the additional parameter. But the
> idea was to seamlessly support existing opclasses / not breaking them
> unnecessarily (I know we don't guarantee that in major upgrades, but as
> they may not benefit from this, why break them?). It'd simplify the code
> in brin.c a little bit, but the opclasses a bit more complex.
Well, I doubt any opclass-support functions exist outside of core.
Or am I just outdated and we do know of some?
--
Álvaro Herrera Valdivia, Chile
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2021-03-03 00:50:15 | Re: PROXY protocol support |
Previous Message | Jacob Champion | 2021-03-03 00:07:22 | Re: Confusing behavior of psql's \e |