summaryrefslogtreecommitdiff
path: root/src/backend/optimizer/path/allpaths.c
diff options
context:
space:
mode:
authorPeter Eisentraut <peter@eisentraut.org>2025-04-06 14:43:51 +0200
committerPeter Eisentraut <peter@eisentraut.org>2025-04-06 14:43:51 +0200
commita8025f544854ad8b865c6b4509030ee84aa8f4a0 (patch)
tree845091557eeb98a01ef6ce7ca0e26315f67e8cfc /src/backend/optimizer/path/allpaths.c
parent3a1a7c5a7071c75676c15b26e242c7df17560bd1 (diff)
Relax ordering-related hardcoded btree requirements in planning
There were several places in ordering-related planning where a requirement for btree was hardcoded but an amcanorder index could suffice. This fixes that. We just need to do the necessary mapping between strategy numbers and compare types and adjust some related APIs so that this works independent of btree strategy numbers. For instance, non-btree amcanorder indexes can now be used to support sorting and merge joins. Also, predtest.c works independent of btree strategy numbers now. To avoid performance regressions, some details on btree and other built-in index types are still hardcoded as shortcuts, but other index types now have access to the same features by providing the required flags and callbacks. Author: Mark Dilger <mark.dilger@enterprisedb.com> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/flat/E72EAA49-354D-4C2E-8EB9-255197F55330@enterprisedb.com
Diffstat (limited to 'src/backend/optimizer/path/allpaths.c')
-rw-r--r--src/backend/optimizer/path/allpaths.c28
1 files changed, 13 insertions, 15 deletions
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index df3453f99f0..905250b3325 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -2313,16 +2313,15 @@ find_window_run_conditions(Query *subquery, RangeTblEntry *rte, Index rti,
runopexpr = NULL;
runoperator = InvalidOid;
- opinfos = get_op_btree_interpretation(opexpr->opno);
+ opinfos = get_op_index_interpretation(opexpr->opno);
foreach(lc, opinfos)
{
- OpBtreeInterpretation *opinfo = (OpBtreeInterpretation *) lfirst(lc);
- int strategy = opinfo->strategy;
+ OpIndexInterpretation *opinfo = (OpIndexInterpretation *) lfirst(lc);
+ CompareType cmptype = opinfo->cmptype;
/* handle < / <= */
- if (strategy == BTLessStrategyNumber ||
- strategy == BTLessEqualStrategyNumber)
+ if (cmptype == COMPARE_LT || cmptype == COMPARE_LE)
{
/*
* < / <= is supported for monotonically increasing functions in
@@ -2339,8 +2338,7 @@ find_window_run_conditions(Query *subquery, RangeTblEntry *rte, Index rti,
break;
}
/* handle > / >= */
- else if (strategy == BTGreaterStrategyNumber ||
- strategy == BTGreaterEqualStrategyNumber)
+ else if (cmptype == COMPARE_GT || cmptype == COMPARE_GE)
{
/*
* > / >= is supported for monotonically decreasing functions in
@@ -2357,9 +2355,9 @@ find_window_run_conditions(Query *subquery, RangeTblEntry *rte, Index rti,
break;
}
/* handle = */
- else if (strategy == BTEqualStrategyNumber)
+ else if (cmptype == COMPARE_EQ)
{
- int16 newstrategy;
+ CompareType newcmptype;
/*
* When both monotonically increasing and decreasing then the
@@ -2383,19 +2381,19 @@ find_window_run_conditions(Query *subquery, RangeTblEntry *rte, Index rti,
* below the value in the equality condition.
*/
if (res->monotonic & MONOTONICFUNC_INCREASING)
- newstrategy = wfunc_left ? BTLessEqualStrategyNumber : BTGreaterEqualStrategyNumber;
+ newcmptype = wfunc_left ? COMPARE_LE : COMPARE_GE;
else
- newstrategy = wfunc_left ? BTGreaterEqualStrategyNumber : BTLessEqualStrategyNumber;
+ newcmptype = wfunc_left ? COMPARE_GE : COMPARE_LE;
/* We must keep the original equality qual */
*keep_original = true;
runopexpr = opexpr;
/* determine the operator to use for the WindowFuncRunCondition */
- runoperator = get_opfamily_member(opinfo->opfamily_id,
- opinfo->oplefttype,
- opinfo->oprighttype,
- newstrategy);
+ runoperator = get_opfamily_member_for_cmptype(opinfo->opfamily_id,
+ opinfo->oplefttype,
+ opinfo->oprighttype,
+ newcmptype);
break;
}
}