Re: WIP: BRIN multi-range indexes
От | Tomas Vondra |
---|---|
Тема | Re: WIP: BRIN multi-range indexes |
Дата | |
Msg-id | d8944e2f-f11d-9757-5cb6-ce064af98690@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: WIP: BRIN multi-range indexes (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-hackers |
On 3/23/21 7:28 PM, Alvaro Herrera wrote: > 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. > I've pushed a cleanup of the unnecessary pg_amproc entries for the built-in opclasses, and I have omitted them from the definition of the new opclasses. Buildfarm seems happy, so far. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: