Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit10f719a

Browse files
committed
Change build_index_pathkeys() so that the expressions it builds to represent
index key columns always have the type expected by the index's associatedoperators, ie, we add RelabelType nodes when dealing with binary-compatibleindex opclasses. This is needed to get varchar indexes to play nicely withthe new EquivalenceClass machinery, as per recent gripe from Josh Berkus thatCVS HEAD was failing to match a varchar index column to a constant restrictionin the query.It seems likely that this change will allow removal of a lot of ugly ad-hocRelabelType-stripping that the planner has traditionally done while matchingexpressions to other expressions, but I'll worry about that some other day.
1 parent7ce9b36 commit10f719a

File tree

3 files changed

+41
-14
lines changed

3 files changed

+41
-14
lines changed

‎src/backend/optimizer/path/pathkeys.c‎

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,13 +11,14 @@
1111
* Portions Copyright (c) 1994, Regents of the University of California
1212
*
1313
* IDENTIFICATION
14-
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.84 2007/04/15 20:09:28 tgl Exp $
14+
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.85 2007/05/31 16:57:34 tgl Exp $
1515
*
1616
*-------------------------------------------------------------------------
1717
*/
1818
#include"postgres.h"
1919

2020
#include"access/skey.h"
21+
#include"catalog/pg_type.h"
2122
#include"nodes/makefuncs.h"
2223
#include"nodes/plannodes.h"
2324
#include"optimizer/clauses.h"
@@ -493,6 +494,27 @@ build_index_pathkeys(PlannerInfo *root,
493494
indexprs_item=lnext(indexprs_item);
494495
}
495496

497+
/*
498+
* When dealing with binary-compatible indexes, we have to ensure that
499+
* the exposed type of the expression tree matches the declared input
500+
* type of the opclass, except when that is a polymorphic type
501+
* (compare the behavior of parse_coerce.c). This ensures that we can
502+
* correctly match the indexkey expression to expressions we find in
503+
* the query, because arguments of operators that could match the
504+
* index will be cast likewise.
505+
*/
506+
if (exprType((Node*)indexkey)!=index->opcintype[i]&&
507+
!IsPolymorphicType(index->opcintype[i]))
508+
{
509+
/* Strip any existing RelabelType, and add a new one */
510+
while (indexkey&&IsA(indexkey,RelabelType))
511+
indexkey= (Expr*) ((RelabelType*)indexkey)->arg;
512+
indexkey= (Expr*)makeRelabelType(indexkey,
513+
index->opcintype[i],
514+
-1,
515+
COERCE_DONTCARE);
516+
}
517+
496518
/* OK, make a canonical pathkey for this sort key */
497519
cpathkey=make_pathkey_from_sortinfo(root,
498520
indexkey,

‎src/backend/optimizer/util/plancat.c‎

Lines changed: 11 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@
99
*
1010
*
1111
* IDENTIFICATION
12-
* $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.135 2007/05/25 17:54:25 tgl Exp $
12+
* $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.136 2007/05/31 16:57:34 tgl Exp $
1313
*
1414
*-------------------------------------------------------------------------
1515
*/
@@ -171,20 +171,23 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
171171
info->ncolumns=ncolumns=index->indnatts;
172172

173173
/*
174-
* Need to make opfamily array large enough to put a terminating
175-
* zero at the end.
174+
* Allocate per-column info arrays. To save a few palloc cycles
175+
* we allocate all the Oid-type arrays in one request. Note that
176+
* the opfamily array needs an extra, terminating zero at the end.
177+
* We pre-zero the ordering info in case the index is unordered.
176178
*/
177179
info->indexkeys= (int*)palloc(sizeof(int)*ncolumns);
178-
info->opfamily= (Oid*)palloc0(sizeof(Oid)* (ncolumns+1));
179-
/* initialize these to zeroes in case index is unordered */
180-
info->fwdsortop=(Oid*)palloc0(sizeof(Oid)*ncolumns);
181-
info->revsortop=(Oid*)palloc0(sizeof(Oid)*ncolumns);
180+
info->opfamily= (Oid*)palloc0(sizeof(Oid)* (4*ncolumns+1));
181+
info->opcintype=info->opfamily+ (ncolumns+1);
182+
info->fwdsortop=info->opcintype+ncolumns;
183+
info->revsortop=info->fwdsortop+ncolumns;
182184
info->nulls_first= (bool*)palloc0(sizeof(bool)*ncolumns);
183185

184186
for (i=0;i<ncolumns;i++)
185187
{
186-
info->opfamily[i]=indexRelation->rd_opfamily[i];
187188
info->indexkeys[i]=index->indkey.values[i];
189+
info->opfamily[i]=indexRelation->rd_opfamily[i];
190+
info->opcintype[i]=indexRelation->rd_opcintype[i];
188191
}
189192

190193
info->relam=indexRelation->rd_rel->relam;

‎src/include/nodes/relation.h‎

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
88
* Portions Copyright (c) 1994, Regents of the University of California
99
*
10-
* $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.143 2007/05/22 23:23:57 tgl Exp $
10+
* $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.144 2007/05/31 16:57:34 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -370,10 +370,11 @@ typedef struct RelOptInfo
370370
*and indexes, but that created confusion without actually doing anything
371371
*useful. So now we have a separate IndexOptInfo struct for indexes.
372372
*
373-
*opfamily[], indexkeys[], fwdsortop[], revsortop[], and nulls_first[]
374-
*each have ncolumns entries. Note: for historical reasons, the
375-
*opfamily array has an extra entry that is always zero. Some code
376-
*scans until it sees a zero entry, rather than looking at ncolumns.
373+
*opfamily[], indexkeys[], opcintype[], fwdsortop[], revsortop[],
374+
*and nulls_first[] each have ncolumns entries.
375+
*Note: for historical reasons, the opfamily array has an extra entry
376+
*that is always zero. Some code scans until it sees a zero entry,
377+
*rather than looking at ncolumns.
377378
*
378379
*Zeroes in the indexkeys[] array indicate index columns that are
379380
*expressions; there is one element in indexprs for each such column.
@@ -402,6 +403,7 @@ typedef struct IndexOptInfo
402403
intncolumns;/* number of columns in index */
403404
Oid*opfamily;/* OIDs of operator families for columns */
404405
int*indexkeys;/* column numbers of index's keys, or 0 */
406+
Oid*opcintype;/* OIDs of opclass declared input data types */
405407
Oid*fwdsortop;/* OIDs of sort operators for each column */
406408
Oid*revsortop;/* OIDs of sort operators for backward scan */
407409
bool*nulls_first;/* do NULLs come first in the sort order? */

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp