Re: pgsql: Generalize hash and ordering support in amapi

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Generalize hash and ordering support in amapi
Date: 2025-03-07 11:05:53
Message-ID: 0f6a8a8a-b42e-433b-89cd-ee121d0919b3@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2025-03-07 14:12:34 pgsql: doc: Add missing decimal places to example rowcount.
Previous Message Peter Eisentraut 2025-03-07 10:57:22 pgsql: Rename amcancrosscompare