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.
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 |