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-23 18:28:50 |
Message-ID: | 20210323182850.GA22408@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Mar-23, Tomas Vondra wrote:
> FWIW there's yet another difference between the current BRIN opclass
> definition, compared to what CREATE OPERATOR CLASS would do. Or more
> precisely, how we'd define opfamily for the cross-type cases (integer,
> float and timestamp cases).
>
> AFAICS we don't really need pg_amproc entries for the cross-type cases,
> we just need the operators, so pg_amproc entries like
>
> { amprocfamily => 'brin/datetime_minmax_ops', amproclefttype =>
> 'timestamptz',
> amprocrighttype => 'timestamp', amprocnum => '1',
> amproc => 'brin_minmax_opcinfo' },
>
> are unnecessary. The attached patch cleans that up, without breaking any
> regression tests. Or is there a reason why we need those?
... ooh ...
When you say "just the operators" you mean the pg_amop entries, right?
I think I agree -- cross-type amproc entries are unlikely to have any
use.
--
Álvaro Herrera Valdivia, Chile
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-03-23 18:30:33 | Re: Change default of checkpoint_completion_target |
Previous Message | Bruce Momjian | 2021-03-23 18:25:01 | Re: pg_upgrade failing for 200+ million Large Objects |