From 74ad49c02e318075f37e7992a12630f9fa2638f4 Mon Sep 17 00:00:00 2001 From: dan Date: Thu, 21 May 2015 20:26:37 +0000 Subject: [PATCH] Have r-tree prefer to use the constraint "col MATCH ?" over "rowid = ?". FossilOrigin-Name: b9e45596d823a6659f4ce2450afcd703feb788d8 --- ext/rtree/rtree.c | 15 ++++++++++++++- ext/rtree/rtreeE.test | 8 ++++++++ manifest | 19 ++++++++----------- manifest.uuid | 2 +- 4 files changed, 31 insertions(+), 13 deletions(-) diff --git a/ext/rtree/rtree.c b/ext/rtree/rtree.c index aed7240dff..3521352b78 100644 --- a/ext/rtree/rtree.c +++ b/ext/rtree/rtree.c @@ -1672,17 +1672,30 @@ static int rtreeBestIndex(sqlite3_vtab *tab, sqlite3_index_info *pIdxInfo){ Rtree *pRtree = (Rtree*)tab; int rc = SQLITE_OK; int ii; + int bMatch = 0; /* True if there exists a MATCH constraint */ i64 nRow; /* Estimated rows returned by this scan */ int iIdx = 0; char zIdxStr[RTREE_MAX_DIMENSIONS*8+1]; memset(zIdxStr, 0, sizeof(zIdxStr)); + /* Check if there exists a MATCH constraint - even an unusable one. If there + ** is, do not consider the lookup-by-rowid plan as using such a plan would + ** require the VDBE to evaluate the MATCH constraint, which is not currently + ** possible. */ + for(ii=0; iinConstraint; ii++){ + if( pIdxInfo->aConstraint[ii].op==SQLITE_INDEX_CONSTRAINT_MATCH ){ + bMatch = 1; + } + } + assert( pIdxInfo->idxStr==0 ); for(ii=0; iinConstraint && iIdx<(int)(sizeof(zIdxStr)-1); ii++){ struct sqlite3_index_constraint *p = &pIdxInfo->aConstraint[ii]; - if( p->usable && p->iColumn==0 && p->op==SQLITE_INDEX_CONSTRAINT_EQ ){ + if( bMatch==0 && p->usable + && p->iColumn==0 && p->op==SQLITE_INDEX_CONSTRAINT_EQ + ){ /* We have an equality constraint on the rowid. Use strategy 1. */ int jj; for(jj=0; jj