mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03:00
Fix matching of boolean index columns to sort ordering.
Normally, if we have a WHERE clause like "indexcol = constant", the planner will figure out that that index column can be ignored when determining whether the index has a desired sort ordering. But this failed to work for boolean index columns, because a condition like "boolcol = true" is canonicalized to just "boolcol" which does not give rise to an EquivalenceClass. Add a check to allow the same type of deduction to be made in this case too. Per a complaint from Dima Pavlov. Arguably this is a bug, but given the limited impact and the small number of complaints so far, I won't risk destabilizing plans in stable branches by back-patching. Patch by me, reviewed by Michael Paquier Discussion: https://postgr.es/m/1788.1481605684@sss.pgh.pa.us
This commit is contained in:
@ -3025,6 +3025,52 @@ relation_has_unique_index_for(PlannerInfo *root, RelOptInfo *rel,
|
||||
return false;
|
||||
}
|
||||
|
||||
/*
|
||||
* indexcol_is_bool_constant_for_query
|
||||
*
|
||||
* If an index column is constrained to have a constant value by the query's
|
||||
* WHERE conditions, then it's irrelevant for sort-order considerations.
|
||||
* Usually that means we have a restriction clause WHERE indexcol = constant,
|
||||
* which gets turned into an EquivalenceClass containing a constant, which
|
||||
* is recognized as redundant by build_index_pathkeys(). But if the index
|
||||
* column is a boolean variable (or expression), then we are not going to
|
||||
* see WHERE indexcol = constant, because expression preprocessing will have
|
||||
* simplified that to "WHERE indexcol" or "WHERE NOT indexcol". So we are not
|
||||
* going to have a matching EquivalenceClass (unless the query also contains
|
||||
* "ORDER BY indexcol"). To allow such cases to work the same as they would
|
||||
* for non-boolean values, this function is provided to detect whether the
|
||||
* specified index column matches a boolean restriction clause.
|
||||
*/
|
||||
bool
|
||||
indexcol_is_bool_constant_for_query(IndexOptInfo *index, int indexcol)
|
||||
{
|
||||
ListCell *lc;
|
||||
|
||||
/* If the index isn't boolean, we can't possibly get a match */
|
||||
if (!IsBooleanOpfamily(index->opfamily[indexcol]))
|
||||
return false;
|
||||
|
||||
/* Check each restriction clause for the index's rel */
|
||||
foreach(lc, index->rel->baserestrictinfo)
|
||||
{
|
||||
RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
|
||||
|
||||
/*
|
||||
* As in match_clause_to_indexcol, never match pseudoconstants to
|
||||
* indexes. (It might be semantically okay to do so here, but the
|
||||
* odds of getting a match are negligible, so don't waste the cycles.)
|
||||
*/
|
||||
if (rinfo->pseudoconstant)
|
||||
continue;
|
||||
|
||||
/* See if we can match the clause's expression to the index column */
|
||||
if (match_boolean_index_clause((Node *) rinfo->clause, indexcol, index))
|
||||
return true;
|
||||
}
|
||||
|
||||
return false;
|
||||
}
|
||||
|
||||
|
||||
/****************************************************************************
|
||||
* ---- ROUTINES TO CHECK OPERANDS ----
|
||||
|
@ -480,17 +480,30 @@ build_index_pathkeys(PlannerInfo *root,
|
||||
index->rel->relids,
|
||||
false);
|
||||
|
||||
/*
|
||||
* If the sort key isn't already present in any EquivalenceClass, then
|
||||
* it's not an interesting sort order for this query. So we can stop
|
||||
* now --- lower-order sort keys aren't useful either.
|
||||
*/
|
||||
if (!cpathkey)
|
||||
break;
|
||||
|
||||
/* Add to list unless redundant */
|
||||
if (!pathkey_is_redundant(cpathkey, retval))
|
||||
retval = lappend(retval, cpathkey);
|
||||
if (cpathkey)
|
||||
{
|
||||
/*
|
||||
* We found the sort key in an EquivalenceClass, so it's relevant
|
||||
* for this query. Add it to list, unless it's redundant.
|
||||
*/
|
||||
if (!pathkey_is_redundant(cpathkey, retval))
|
||||
retval = lappend(retval, cpathkey);
|
||||
}
|
||||
else
|
||||
{
|
||||
/*
|
||||
* Boolean index keys might be redundant even if they do not
|
||||
* appear in an EquivalenceClass, because of our special treatment
|
||||
* of boolean equality conditions --- see the comment for
|
||||
* indexcol_is_bool_constant_for_query(). If that applies, we can
|
||||
* continue to examine lower-order index columns. Otherwise, the
|
||||
* sort key is not an interesting sort order for this query, so we
|
||||
* should stop considering index columns; any lower-order sort
|
||||
* keys won't be useful either.
|
||||
*/
|
||||
if (!indexcol_is_bool_constant_for_query(index, i))
|
||||
break;
|
||||
}
|
||||
|
||||
i++;
|
||||
}
|
||||
|
Reference in New Issue
Block a user