Re: pgsql: Generalize hash and ordering support in amapi - Mailing list pgsql-committers

From Peter Eisentraut
Subject Re: pgsql: Generalize hash and ordering support in amapi
Date
Msg-id 0f6a8a8a-b42e-433b-89cd-ee121d0919b3@eisentraut.org
Whole thread Raw
In response to Re: pgsql: Generalize hash and ordering support in amapi  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Generalize hash and ordering support in amapi
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Improve possible performance regression
Next
From: Robert Haas
Date:
Subject: pgsql: doc: Add missing decimal places to example rowcount.