Re: pgsql: Generalize hash and ordering support in amapi
От | Peter Eisentraut |
---|---|
Тема | Re: pgsql: Generalize hash and ordering support in amapi |
Дата | |
Msg-id | 0f6a8a8a-b42e-433b-89cd-ee121d0919b3@eisentraut.org обсуждение исходный текст |
Ответ на | Re: pgsql: Generalize hash and ordering support in amapi (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Generalize hash and ordering support in amapi
|
Список | pgsql-committers |
On 04.03.25 18:35, Tom Lane wrote: > In any case, my gripe was less about the name of the flag and more > about the lack of a clear specification of what it means. "does AM > support cross-type comparisons" doesn't get the job done. Maybe > we can fit > > /* do operators within an opfamily have consistent equality semantics? */ > bool amconsistentequality; > /* do operators within an opfamily have consistent ordering semantics? */ > bool amconsistentordering; > Also, I'm thinking that equality_ops_are_compatible and > comparison_ops_are_compatible now have a bit of a performance problem. > The original coding was intended to provide a cheap check before > expending the cycles to test op_in_opfamily. This patch has > completely blown that up, since GetIndexAmRoutineByAmId is *more* > expensive than op_in_opfamily. I suggest reversing things so that we > test op_in_opfamily first and only bother to look up the AM details > when we've verified that both operators belong to the same family. I have committed fixes for these issues along the lines you suggested.
В списке pgsql-committers по дате отправления: