~ubuntu-branches/ubuntu/trusty/drizzle/trusty

« back to all changes in this revision

Viewing changes to tests/randgen/conf/optimizer/optimizer_no_subquery.yy

  • Committer: Package Import Robot
  • Author(s): Clint Byrum
  • Date: 2012-06-19 10:46:49 UTC
  • mfrom: (1.1.6)
  • mto: This revision was merged to the branch mainline in revision 29.
  • Revision ID: package-import@ubuntu.com-20120619104649-e2l0ggd4oz3um0f4
Tags: upstream-7.1.36-stable
ImportĀ upstreamĀ versionĀ 7.1.36-stable

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
# Copyright (C) 2008-2010 Sun Microsystems, Inc. All rights reserved.
 
2
# Use is subject to license terms.
 
3
#
 
4
# This program is free software; you can redistribute it and/or modify
 
5
# it under the terms of the GNU General Public License as published by
 
6
# the Free Software Foundation; version 2 of the License.
 
7
#
 
8
# This program is distributed in the hope that it will be useful, but
 
9
# WITHOUT ANY WARRANTY; without even the implied warranty of
 
10
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 
11
# General Public License for more details.
 
12
#
 
13
# You should have received a copy of the GNU General Public License
 
14
# along with this program; if not, write to the Free Software
 
15
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
 
16
# USA
 
17
 
 
18
# **NOTE** Joins for this grammar are currently not working as intended.
 
19
# For example, if we have tables 1, 2, and 3, we end up with ON conditions that 
 
20
# only involve tables 2 and 3.
 
21
# This will be fixed, but initial attempts at altering this had a negative 
 
22
# impact on the coverage the test was providing.  To be fixed when scheduling 
 
23
# permits.  We are still seeing significant coverage with the grammar as-is.
 
24
 
 
25
################################################################################
 
26
# optimizer_no_subquery.yy:  Random Query Generator grammar for testing        #
 
27
#                            non-subquery optimizations.  This grammar         #
 
28
#                            *should* hit the optimizations listed here:       #
 
29
#                    https://inside.mysql.com/wiki/Optimizer_grammar_worksheet #
 
30
# see:  WL#5006 Random Query Generator testing of Azalea Optimizer- subqueries #
 
31
#       https://intranet.mysql.com/worklog/QA-Sprint/?tid=5006                 #
 
32
#                                                                              #
 
33
# recommendations:                                                             #
 
34
#       queries: 10k+.  We can see a lot with lower values, but over 10k is    #
 
35
#                best.  The intersect optimization happens with low frequency  #
 
36
#                so larger values help us to hit it at least some of the time  #
 
37
#       engines: MyISAM, Innodb, Memory.  Certain optimizations are only hit with #
 
38
#                one engine or another and we should use both to ensure we     #
 
39
#                are getting maximum coverage                                  #
 
40
#       Validators:  ResultsetComparatorSimplify                               #
 
41
#                      - used on server-server comparisons                     #
 
42
#                    Transformer - used on a single server                     #
 
43
#                      - creates equivalent versions of a single query         # 
 
44
#                    SelectStability - used on a single server                 #
 
45
#                      - ensures the same query produces stable result sets    #
 
46
################################################################################
 
47
 
 
48
################################################################################
 
49
# The perl code in {} helps us with bookkeeping for writing more sensible      #
 
50
# queries.  We need to keep track of these items to ensure we get interesting  #
 
51
# and stable queries that find bugs rather than wondering if our query is      #
 
52
# dodgy.                                                                       #
 
53
################################################################################
 
54
query:
 
55
        { @nonaggregates = () ; $tables = 0 ; $fields = 0 ; "" } query_type ;
 
56
 
 
57
 
 
58
query_type:
 
59
        main_select | main_select | main_select |  loose_scan ;
 
60
 
 
61
################################################################################
 
62
# The loose* rules listed below are to hit the 'Using index for group-by'       #
 
63
# optimization.  This optimization has some strict requirements, thus          #
 
64
# we needed a separate query pattern to ensure we hit it.                      #
 
65
################################################################################
 
66
loose_scan:
 
67
        SELECT distinct loose_select_clause
 
68
        FROM new_table_item
 
69
        WHERE generic_where_list
 
70
        group_by_clause ;
 
71
 
 
72
loose_select_clause:
 
73
        loose_select_list |
 
74
        MIN( _field_indexed) AS { "field".++$fields } , loose_select_list |
 
75
        MAX( _field_indexed) AS { "field".++$fields } , loose_select_list |
 
76
        MIN( _field_indexed[invariant] ) AS { "field".++$fields }, MAX( _field_indexed[invariant] ) AS { "field".++$fields }, loose_select_list ;
 
77
 
 
78
loose_select_list:
 
79
        loose_select_item | 
 
80
        loose_select_item , loose_select_list ;
 
81
 
 
82
loose_select_item:
 
83
        _field AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } ;                
 
84
        
 
85
################################################################################
 
86
# The bulk of interesting things happen with this main rule                    #
 
87
################################################################################
 
88
main_select:
 
89
        simple_select | simple_select | aggregate_select | 
 
90
        mixed_select |  mixed_select | mixed_select ;
 
91
 
 
92
mixed_select:
 
93
        SELECT distinct straight_join select_option select_list
 
94
        FROM join_list
 
95
        where_clause
 
96
        group_by_clause
 
97
        having_clause
 
98
        order_by_clause ;
 
99
 
 
100
simple_select:
 
101
        SELECT distinct straight_join select_option simple_select_list
 
102
        FROM join_list
 
103
        where_clause
 
104
        optional_group_by
 
105
        having_clause
 
106
        order_by_clause ;
 
107
 
 
108
aggregate_select:
 
109
        SELECT distinct straight_join select_option aggregate_select_list
 
110
        FROM join_list
 
111
        where_clause
 
112
        optional_group_by
 
113
        having_clause
 
114
        order_by_clause ;
 
115
 
 
116
distinct: DISTINCT | | | |  ;
 
117
 
 
118
select_option:  | | | | | | | | | SQL_SMALL_RESULT ;
 
119
 
 
120
straight_join:  | | | | | | | | | | | | | | | | | | | | | STRAIGHT_JOIN ;
 
121
 
 
122
select_list:
 
123
        new_select_item |
 
124
        new_select_item , select_list |
 
125
        new_select_item , select_list ;
 
126
 
 
127
simple_select_list:
 
128
        nonaggregate_select_item |
 
129
        nonaggregate_select_item , simple_select_list |
 
130
        nonaggregate_select_item , simple_select_list ;
 
131
 
 
132
aggregate_select_list:
 
133
        aggregate_select_item | aggregate_select_item |
 
134
        aggregate_select_item, aggregate_select_list ;
 
135
 
 
136
join_list:
 
137
################################################################################
 
138
# this limits us to 2 and 3 table joins / can use it if we hit                 #
 
139
# too many mega-join conditions which take too long to run                     #
 
140
################################################################################
 
141
        ( new_table_item join_type new_table_item ON (join_condition_list ) ) |
 
142
        ( new_table_item join_type ( ( new_table_item join_type new_table_item ON (join_condition_list ) ) ) ON (join_condition_list ) ) ;
 
143
 
 
144
join_list_disabled:
 
145
################################################################################
 
146
# preventing deep join nesting for run time / table access methods are more    #
 
147
# important here - join.yy can provide deeper join coverage                    #
 
148
# Enabling this / swapping out with join_list above can produce some           #
 
149
# time-consuming queries.                                                      #
 
150
################################################################################
 
151
 
 
152
        new_table_item |
 
153
        ( new_table_item join_type join_list ON (join_condition_list ) ) ;
 
154
 
 
155
join_type:
 
156
        INNER JOIN | left_right outer JOIN | STRAIGHT_JOIN ;  
 
157
 
 
158
join_condition_list:
 
159
    join_condition_item | 
 
160
    ( join_condition_item ) and_or ( join_condition_item ) |
 
161
    ( current_table_item  .`pk` arithmetic_operator previous_table_item . _field ) AND (current_table_item  .`pk` arithmetic_operator previous_table_item . _field ) ;    
 
162
 
 
163
join_condition_item:
 
164
     current_table_item . int_indexed = previous_table_item . int_field_name  |
 
165
     current_table_item . int_field_name = previous_table_item . int_indexed  |
 
166
     current_table_item . `col_varchar_key` = previous_table_item . char_field_name |
 
167
     current_table_item . char_field_name = previous_table_item . `col_varchar_key` |
 
168
     current_table_item . int_indexed arithmetic_operator previous_table_item . int_field_name  |
 
169
     current_table_item . int_field_name arithmetic_operator previous_table_item . int_indexed  |
 
170
     current_table_item . `col_varchar_key` arithmetic_operator previous_table_item . char_field_name |
 
171
     current_table_item . char_field_name arithmetic_operator previous_table_item . `col_varchar_key`;
 
172
 
 
173
 
 
174
left_right:
 
175
        LEFT | RIGHT ;
 
176
 
 
177
outer:
 
178
        | OUTER ;
 
179
 
 
180
where_clause:
 
181
        | WHERE where_list ;
 
182
 
 
183
 
 
184
where_list:
 
185
        generic_where_list |
 
186
        range_predicate1_list | range_predicate2_list |
 
187
        range_predicate1_list and_or generic_where_list |
 
188
        range_predicate2_list and_or generic_where_list ;
 
189
 
 
190
 
 
191
generic_where_list:
 
192
        where_item |
 
193
        ( where_list and_or where_item ) ;
 
194
 
 
195
not:
 
196
        | | | NOT;
 
197
 
 
198
################################################################################
 
199
# The IS not NULL values in where_item are to hit the ref_or_null and          #
 
200
# the not_exists optimizations.  The LIKE '%a%' rule is to try to hit the      #
 
201
# rnd_pos optimization                                                         #
 
202
################################################################################
 
203
where_item:
 
204
        alias1 .`pk` arithmetic_operator existing_table_item . _field  |
 
205
        alias1 .`pk` arithmetic_operator existing_table_item . _field  |
 
206
        existing_table_item . _field arithmetic_operator value  |
 
207
        existing_table_item . _field arithmetic_operator existing_table_item . _field |
 
208
        existing_table_item . _field arithmetic_operator value  |
 
209
        existing_table_item . _field arithmetic_operator existing_table_item . _field |
 
210
        alias1 .`pk` IS not NULL |
 
211
        alias1 . _field IS not NULL |
 
212
        alias1 . _field_indexed arithmetic_operator value AND ( alias1 . char_field_name LIKE '%a%' OR alias1.char_field_name LIKE '%b%') ;
 
213
 
 
214
################################################################################
 
215
# The range_predicate_1* rules below are in place to ensure we hit the         #
 
216
# index_merge/sort_union optimization.                                         #
 
217
# NOTE: combinations of the predicate_1 and predicate_2 rules tend to hit the  #
 
218
# index_merge/intersect optimization                                           #
 
219
################################################################################
 
220
 
 
221
range_predicate1_list:
 
222
      range_predicate1_item | 
 
223
      ( range_predicate1_item OR range_predicate1_list ) ;
 
224
 
 
225
range_predicate1_item:
 
226
         alias1 . int_indexed not BETWEEN _tinyint_unsigned[invariant] AND ( _tinyint_unsigned[invariant] + _tinyint_unsigned ) |
 
227
         alias1 . `col_varchar_key` arithmetic_operator _char[invariant]  |
 
228
         alias1 . int_indexed not IN (number_list) |
 
229
         alias1 . `col_varchar_key` not IN (char_list) |
 
230
         alias1 . `pk` > _tinyint_unsigned[invariant] AND alias1 . `pk` < ( _tinyint_unsigned[invariant] + _tinyint_unsigned ) |
 
231
         alias1 . `col_int_key` > _tinyint_unsigned[invariant] AND alias1 . `col_int_key` < ( _tinyint_unsigned[invariant] + _tinyint_unsigned ) ;
 
232
 
 
233
################################################################################
 
234
# The range_predicate_2* rules below are in place to ensure we hit the         #
 
235
# index_merge/union optimization.                                              #
 
236
# NOTE: combinations of the predicate_1 and predicate_2 rules tend to hit the  #
 
237
# index_merge/intersect optimization                                           #
 
238
################################################################################
 
239
 
 
240
range_predicate2_list:
 
241
      range_predicate2_item | 
 
242
      ( range_predicate2_item and_or range_predicate2_list ) ;
 
243
 
 
244
range_predicate2_item:
 
245
        alias1 . `pk` = _tinyint_unsigned |
 
246
        alias1 . `col_int_key` = _tinyint_unsigned |
 
247
        alias1 . `col_varchar_key` = _char |
 
248
        alias1 . int_indexed = _tinyint_unsigned |
 
249
        alias1 . `col_varchar_key` = _char |
 
250
        alias1 . int_indexed = existing_table_item . int_indexed |
 
251
        alias1 . `col_varchar_key` = existing_table_item . `col_varchar_key` ;
 
252
 
 
253
################################################################################
 
254
# The number and char_list rules are for creating WHERE conditions that test   #
 
255
# 'field' IN (list_of_items)                                                   #
 
256
################################################################################
 
257
number_list:
 
258
        _tinyint_unsigned | number_list, _tinyint_unsigned ;
 
259
 
 
260
char_list: 
 
261
        _char | char_list, _char ;
 
262
 
 
263
################################################################################
 
264
# We ensure that a GROUP BY statement includes all nonaggregates.              #
 
265
# This helps to ensure the query is more useful in detecting real errors /     #
 
266
# that the query doesn't lend itself to variable result sets                   #
 
267
################################################################################
 
268
group_by_clause:
 
269
        { scalar(@nonaggregates) > 0 ? " GROUP BY ".join (', ' , @nonaggregates ) : "" }  ;
 
270
 
 
271
optional_group_by:
 
272
        | | group_by_clause ;
 
273
 
 
274
having_clause:
 
275
        | HAVING having_list;
 
276
 
 
277
having_list:
 
278
        having_item |
 
279
        having_item |
 
280
        (having_list and_or having_item)  ;
 
281
 
 
282
having_item:
 
283
        existing_select_item arithmetic_operator value ;
 
284
 
 
285
################################################################################
 
286
# We use the total_order_by rule when using the LIMIT operator to ensure that  #
 
287
# we have a consistent result set - server1 and server2 should not differ      #
 
288
################################################################################
 
289
 
 
290
order_by_clause:
 
291
        |
 
292
        ORDER BY total_order_by , alias1 . _field_indexed desc limit |
 
293
        ORDER BY order_by_list |
 
294
        ORDER BY total_order_by,  order_by_list limit ;
 
295
 
 
296
total_order_by:
 
297
        { join(', ', map { "field".$_ } (1..$fields) ) };
 
298
 
 
299
order_by_list:
 
300
        order_by_item  |
 
301
        order_by_item  , order_by_list ;
 
302
 
 
303
order_by_item:
 
304
        alias1 . _field_indexed , existing_table_item .`pk` desc  |
 
305
        alias1 . _field_indexed desc |
 
306
        existing_select_item desc ;
 
307
 
 
308
desc:
 
309
        ASC | | DESC ; 
 
310
 
 
311
################################################################################
 
312
# We mix digit and _digit here.  We want to alter the possible values of LIMIT #
 
313
# To ensure we hit varying EXPLAIN plans, but the OFFSET can be smaller        #
 
314
################################################################################
 
315
 
 
316
limit:
 
317
        | | LIMIT limit_size | LIMIT limit_size OFFSET _digit;
 
318
 
 
319
new_select_item:
 
320
        nonaggregate_select_item |
 
321
        nonaggregate_select_item |
 
322
        nonaggregate_select_item |        
 
323
        nonaggregate_select_item |
 
324
        nonaggregate_select_item |        
 
325
        nonaggregate_select_item |
 
326
        nonaggregate_select_item |        
 
327
        nonaggregate_select_item |
 
328
        aggregate_select_item |
 
329
        combo_select_item ;
 
330
 
 
331
################################################################################
 
332
# We have the perl code here to help us write more sensible queries            #
 
333
# It allows us to use field1...fieldn in the WHERE, ORDER BY, and GROUP BY     #
 
334
# clauses so that the queries will produce more stable and interesting results #
 
335
################################################################################
 
336
 
 
337
nonaggregate_select_item:
 
338
        table_one_two . _field_indexed AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } |
 
339
        table_one_two . _field_indexed AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } |
 
340
        table_one_two . _field AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } ;
 
341
 
 
342
aggregate_select_item:
 
343
        aggregate table_one_two . _field ) AS { "field".++$fields };
 
344
 
 
345
################################################################################
 
346
# The combo_select_items are for 'spice' - we actually found                   #
 
347
################################################################################
 
348
 
 
349
combo_select_item:
 
350
    ( ( table_one_two . int_field_name ) math_operator ( table_one_two . int_field_name ) ) AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } |
 
351
    CONCAT ( table_one_two . char_field_name , table_one_two . char_field_name ) AS { my $f = "field".++$fields ; push @nonaggregates , $f ; $f } ;
 
352
 
 
353
table_one_two:
 
354
        alias1 | alias2 ;
 
355
 
 
356
aggregate:
 
357
        COUNT( distinct | SUM( distinct | MIN( distinct | MAX( distinct ;
 
358
 
 
359
################################################################################
 
360
# The following rules are for writing more sensible queries - that we don't    #
 
361
# reference tables / fields that aren't present in the query and that we keep  #
 
362
# track of what we have added.  You shouldn't need to touch these ever         #
 
363
################################################################################
 
364
new_table_item:
 
365
        _table AS { "alias".++$tables };
 
366
 
 
367
current_table_item:
 
368
        { "alias".$tables };
 
369
 
 
370
previous_table_item:
 
371
        { "alias".($tables - 1) };
 
372
 
 
373
existing_table_item:
 
374
        { "alias".$prng->int(1,$tables) };
 
375
 
 
376
existing_select_item:
 
377
        { "field".$prng->int(1,$fields) };
 
378
################################################################################
 
379
# end of utility rules                                                         #
 
380
################################################################################
 
381
 
 
382
arithmetic_operator:
 
383
        = | > | < | != | <> | <= | >= ;
 
384
 
 
385
################################################################################
 
386
# We are trying to skew the ON condition for JOINs to be largely based on      #
 
387
# equalities, but to still allow other arithmetic operators                    #
 
388
################################################################################
 
389
join_condition_operator:
 
390
    arithmetic_operator | = | = | = ;
 
391
 
 
392
################################################################################
 
393
# Used for creating combo_items - ie (field1 + field2) AS fieldX               #
 
394
# We ignore division to prevent division by zero errors                        #
 
395
################################################################################
 
396
math_operator:
 
397
    + | - | * ;
 
398
 
 
399
################################################################################
 
400
# We stack AND to provide more interesting options for the optimizer           #
 
401
# Alter these percentages at your own risk / look for coverage regressions     #
 
402
# with --debug if you play with these.  Those optimizations that require an    #
 
403
# OR-only list in the WHERE clause are specifically stacked in another rule    #
 
404
################################################################################
 
405
and_or:
 
406
   AND | AND | OR ;
 
407
 
 
408
        
 
409
value:
 
410
        _digit | _digit | _digit | _digit | _tinyint_unsigned|
 
411
        _char(2) | _char(2) | _char(2) | _char(2) | _char(2) ;
 
412
 
 
413
_table:
 
414
     A | B | C | BB | CC | B | C | BB | CC | 
 
415
     C | C | C | C  | C  | C | C | C  | C  |
 
416
     CC | CC | CC | CC | CC | CC | CC | CC |
 
417
     D ;
 
418
 
 
419
################################################################################
 
420
# Add a possibility for 'view' to occur at the end of the previous '_table' rule
 
421
# to allow a chance to use views (when running the RQG with --views)
 
422
################################################################################
 
423
 
 
424
view:
 
425
    view_A | view_B | view_C | view_BB | view_CC ;
 
426
 
 
427
_field:
 
428
    int_field_name | char_field_name ;
 
429
 
 
430
_digit:
 
431
    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | _tinyint_unsigned ;
 
432
 
 
433
 
 
434
int_field_name:
 
435
    `pk` | `col_int_key` | `col_int_nokey` ;
 
436
 
 
437
int_indexed:
 
438
    `pk` | `col_int_key` ;
 
439
 
 
440
 
 
441
char_field_name:
 
442
    `col_varchar_key` | `col_varchar_nokey` ;
 
443
 
 
444
################################################################################
 
445
# We define LIMIT_rows in this fashion as LIMIT values can differ depending on      #
 
446
# how large the LIMIT is - LIMIT 2 = LIMIT 9 != LIMIT 19                       #
 
447
################################################################################
 
448
 
 
449
limit_size:
 
450
    1 | 2 | 10 | 100 | 1000;