Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Turn restriction 20 on the query flattener into an assert since the situation restricted can no longer occur because of the more aggressive use of co-routines. |
|---|---|
| Downloads: | Tarball | ZIP archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
4464f40ccd7c5553f4d44120ca6dac4e |
| User & Date: | drh 2017-10-04 12:06:31.705 |
References
|
2017-10-28
| ||
| 20:51 | Reactivate query flattening when the result set of the outer query has no function calls or subqueries. This is a partial reversal of check-in [c9104b59]. Co-routines are still preferred if the outer query has a complex result set, but for simple results sets, query flattening is used. Check-in [4464f40ccd7] is completely backed out due to this change. (check-in: d17ef7d153 user: drh tags: trunk) | |
Context
|
2017-10-28
| ||
| 20:51 | Reactivate query flattening when the result set of the outer query has no function calls or subqueries. This is a partial reversal of check-in [c9104b59]. Co-routines are still preferred if the outer query has a complex result set, but for simple results sets, query flattening is used. Check-in [4464f40ccd7] is completely backed out due to this change. (check-in: d17ef7d153 user: drh tags: trunk) | |
|
2017-10-04
| ||
| 12:08 | Amend recent changes to busy.test to avoid failing with SQLITE_ENABLE_STAT4 builds. (check-in: 9ff4944194 user: dan tags: trunk) | |
| 12:06 | Turn restriction 20 on the query flattener into an assert since the situation restricted can no longer occur because of the more aggressive use of co-routines. (check-in: 4464f40ccd user: drh tags: trunk) | |
| 10:39 | Add tests to verify that the busy-handler is invoked correctly when processing "PRAGMA optimize" and ANALYZE commands. (check-in: fb83c3d8df user: dan tags: trunk) | |
Changes
Changes to src/select.c.
| ︙ | ︙ | |||
3378 3379 3380 3381 3382 3383 3384 | ** (18) If the sub-query is a compound select, then all terms of the ** ORDER BY clause of the parent must be simple references to ** columns of the sub-query. ** ** (19) If the subquery uses LIMIT then the outer query may not ** have a WHERE clause. ** | | | | | | > | 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 | ** (18) If the sub-query is a compound select, then all terms of the ** ORDER BY clause of the parent must be simple references to ** columns of the sub-query. ** ** (19) If the subquery uses LIMIT then the outer query may not ** have a WHERE clause. ** ** (**) Subsumed into (17d3). Was: If the sub-query is a compound select, ** then it must not use an ORDER BY clause - Ticket #3773. Because ** of (17d3), then only way to have a compound subquery is if it is ** the only term in the FROM clause of the outer query. But if the ** only term in the FROM clause has an ORDER BY, then it will be ** implemented as a co-routine and the flattener will never be called. ** ** (21) If the subquery uses LIMIT then the outer query may not be ** DISTINCT. (See ticket [752e1646fc]). ** ** (22) The subquery may not be a recursive CTE. ** ** (**) Subsumed into restriction (17d3). Was: If the outer query is |
| ︙ | ︙ | |||
3516 3517 3518 3519 3520 3521 3522 |
/* Restriction (17): If the sub-query is a compound SELECT, then it must
** use only the UNION ALL operator. And none of the simple select queries
** that make up the compound SELECT are allowed to be aggregate or distinct
** queries.
*/
if( pSub->pPrior ){
| < < < | 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 |
/* Restriction (17): If the sub-query is a compound SELECT, then it must
** use only the UNION ALL operator. And none of the simple select queries
** that make up the compound SELECT are allowed to be aggregate or distinct
** queries.
*/
if( pSub->pPrior ){
if( isAgg || (p->selFlags & SF_Distinct)!=0 || pSrc->nSrc!=1 ){
return 0; /* (17d1), (17d2), or (17d3) */
}
for(pSub1=pSub; pSub1; pSub1=pSub1->pPrior){
testcase( (pSub1->selFlags & (SF_Distinct|SF_Aggregate))==SF_Distinct );
testcase( (pSub1->selFlags & (SF_Distinct|SF_Aggregate))==SF_Aggregate );
assert( pSub->pSrc!=0 );
|
| ︙ | ︙ | |||
3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 |
** The only way that the recursive part of a CTE can contain a compound
** subquery is for the subquery to be one term of a join. But if the
** subquery is a join, then the flattening has already been stopped by
** restriction (17d3)
*/
assert( (p->selFlags & SF_Recursive)==0 || pSub->pPrior==0 );
/***** If we reach this point, flattening is permitted. *****/
SELECTTRACE(1,pParse,p,("flatten %s.%p from term %d\n",
pSub->zSelName, pSub, iFrom));
/* Authorize the subquery */
pParse->zAuthContext = pSubitem->zName;
TESTONLY(i =) sqlite3AuthCheck(pParse, SQLITE_SELECT, 0, 0, 0);
| > > > > > > > > > | 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 |
** The only way that the recursive part of a CTE can contain a compound
** subquery is for the subquery to be one term of a join. But if the
** subquery is a join, then the flattening has already been stopped by
** restriction (17d3)
*/
assert( (p->selFlags & SF_Recursive)==0 || pSub->pPrior==0 );
/* Ex-restriction (20):
** A compound subquery must be the only term in the FROM clause of the
** outer query by restriction (17d3). But if that term also has an
** ORDER BY clause, then the subquery will be implemented by co-routine
** and so the flattener will never be invoked. Hence, it is not possible
** for the subquery to be a compound and have an ORDER BY clause.
*/
assert( pSub->pPrior==0 || pSub->pOrderBy==0 );
/***** If we reach this point, flattening is permitted. *****/
SELECTTRACE(1,pParse,p,("flatten %s.%p from term %d\n",
pSub->zSelName, pSub, iFrom));
/* Authorize the subquery */
pParse->zAuthContext = pSubitem->zName;
TESTONLY(i =) sqlite3AuthCheck(pParse, SQLITE_SELECT, 0, 0, 0);
|
| ︙ | ︙ |