Optimiser difference : a max() sometimes doing a backward scan and sometimes forward scan

Question

I interested why we get 2 different query plans on Sybase 15.5 and 15.7 for similar queries
declare @MID int
select @MID = 25717
select MID , max(Date) from CB where MID = @MID group by MID
select @MID, max(Date) from CB where MID = @MID
The index is on (MID, Date).
The first does forward scan and the second does a backward scan.
With our data, the first query does 8000 page reads (with a SAN read costing 4ms = 32s)
and the second query does 4 page reads (with a SAN read costing 4ms = 16ms)
1)
|   |   |GROUP SORTED Operator (VA = 1)
|   |   |  Evaluate Grouped MAXIMUM AGGREGATE.
|   |   |
|   |   |   |SCAN Operator (VA = 0)
|   |   |   |  FROM TABLE
|   |   |   |  CB
|   |   |   |  Index : IDX1
|   |   |   |  Forward Scan.
|   |   |   |  Positioning by key.
|   |   |   |  Index contains all needed columns. Base table will not be read.
|   |   |   |  Keys are:
|   |   |   |    MID ASC
|   |   |   |  Using I/O Size 16 Kbytes for index leaf pages.
|   |   |   |  With LRU Buffer Replacement Strategy for index leaf pages.
2)
|   |  Evaluate Ungrouped MAXIMUM AGGREGATE.
|   |  Scanning only up to the first qualifying row.
|   |
|   |   |SCAN Operator (VA = 0)
|   |   |  FROM TABLE
|   |   |  CB
|   |   |  Index : IDX1
|   |   |  Backward scan.
|   |   |  Positioning by key.
|   |   |  Index contains all needed columns. Base table will not be read.
|   |   |  Keys are:
|   |   |    MID ASC
|   |   |  Using I/O Size 2 Kbytes for index leaf pages.
|   |   |  With LRU Buffer Replacement Strategy for index leaf pages.
Why does the optimiser generate different plans ?

Answer 1

Okay - so the one reason I like to see plancost vs. just showplan...you can see in the one without the group by clause that it does a ScalarAgg vs. a GroupSorted ala:
(without group by clause)
==================== Lava Operator Tree ====================
                        Emit                               
                        (VA = 2)                           
                        r:1 er:1                           
                        cpu: 0                             
            ScalarAgg                                      
              Max                                          
            (VA = 1)                                       
            r:1 er:1                                       
            cpu: 0                                         
IndexScan                                                  
IDX1                                                       
(VA = 0)                                                   
r:1 er:1                                                   
l:3 el:3                                                   
p:3 ep:3                                                   
============================================================
(with group by clause)
==================== Lava Operator Tree ====================
                                    Emit                    
                                    (VA = 3)                
                                    r:1 er:8                
                                    cpu: 300                
                        Restrict                            
                        (0)(0)(0)(4)(0)                     
                        (VA = 2)                            
                        r:1 er:8                            
            GroupSorted                                     
            Grouping                                        
            (VA = 1)                                        
            r:1 er:8                                        
IndexScan                                                   
IDX1                                                        
(VA = 0)                                                    
r:353666 er:158986                                          
l:863 el:386                                                
p:176 ep:78                                                 
============================================================
Now the key to the problem is in the GroupSorted function.
But, let's step back a bit.   Query optimization is just one of the many (and nearly final) steps prior to query execution.  Prior to query optimization we have the TDS Receive buffers, the SQL parsing, the SQL normalization and pre-processing.   In the pre-processing, we normally try to construct what is called the LOP (Logical Operator) tree.   Note that no-where in that sequence is any execution - I mention this because once before you commented on someone else's posting about a purported optimization problem with
select * from table where column=<value> or 1=2
....the notion of evaluating 1=2 wouldn't happen until the execution phase - so optimization will not consider it - in this case it looks it at as an expression to be evaluated and skips it.   If you want to see what I mean do a showplan and statistics io on
select * from sysobjects where 1=2
and you will see that due to lack of sargs we do a tablescan from the optimizer due to lack of sargs...but it is during query execution that we short circuit and hence the 0 LIO's.    I point that out because there are different phases involved and in this case it is the pre-processor that selects the overall LOP tree to start with....but then the optimizer has to consider which LOPs to use underneath that such as GroupSorted (using an index) vs. GroupSorting (sort operation), etc.
Soooo....in the GROUP BY example, it starts with:
The Lop tree:
( project
        ( group
                ( scan CB
vs. your other example (without the Group By):
The Lop tree:
( project
        ( scalar
                ( scan CB
....so you can see the difference right off the bat in what the optimizer received from the pre-processor.   Like I pointed out earlier, the problem *started* the second you put the group by clause in - before the optimizer even got to look at.
You then get 2 optimization blocks....the innermost for the (scan CB) and then the outer for (group (inner block)) ala:
OptBlock1
        The Lop tree:
        ( scan CB
        Generic Tables: ( Gtt1( CB ) Gti2( IDX1 ) )
        Generic Columns: (  Gc0(CB ,Rid) Gc1(CB ,MID) Gc2(CB ,ValuationDate))  Virtual Generic Columns: ( )
        Predicates: ( { CB.MID Gtg0.Gc4 }  = 0 tc:{1} )
        Transitive Closures: ( Tc0 = {  Gc0(CB ,Rid)} Tc1 = {  Gc1(CB ,MID) Gc4(Gtg0 ,_gcelement_4)} Tc2 = {  Gc2(CB ,ValuationDate)} )
OptBlock0
        The Lop tree:
        ( pseudoscan
        Generic Tables: ( Gtg0 )
        Generic Columns: (  Gc3(Gtg0 ,_gcelement_3) Gc4(Gtg0 ,_gcelement_4) Gc5(Gtg0 ,_virtualagg) Gc6(Gtg0 ,_virtualagg))  Virtual Generic Columns: ( )
        Predicates: ( { CB.MID Gtg0.Gc4 }  = 0 tc:{1} )
        Transitive Closures: ( Tc3 = {  Gc3(Gtg0 ,_gcelement_3) Gc5(Gtg0 ,_virtualagg) Gc6(Gtg0 ,_virtualagg)} Tc1 = {  Gc1(CB ,MID) Gc4(Gtg0 ,_gcelement_4)} )
The question is, why did we estimate 8 rows returned from the group by????   And would that change the behavior???
That comes from this section:
        ( PopGroupSorted
                proj: {{ CB.MID Gtg0.Gc4 } ,{ Gtg0.Gc3 Gtg0._virtualagg Gtg0._virtualagg } }
                pred: [Tc{} Pe{{ CB.MID Gtg0.Gc4 }  = 0}]
                subs: {CB.MID ,Gtg0._virtualagg }
                cost: 66305.12
                I/O estimate : [
                        rowcount=7.388771
                        averagewidth=19
                        pages=1
                        prefetchpages=1
                        lio=0 pio=0 cpu=158985.8
                        total lio=385.3457 total pio=77.60534 total cpu=635943
                        tempdb=0
                Cache Strategy: [
                        prefetch=YES
                        iosize=131072 Bytes
                        bufreplace=LRU
                order: none
                ( PopIndScan index: Gti2( IDX1 )
                                table: Gtt1( CB )
                        proj: {{ CB.MID Gtg0.Gc4 } ,{ CB.ValuationDate } }
                        pred: [Tc{} Pe{{ CB.MID Gtg0.Gc4 }  = 0}]
                        subs: {CB.MID ,CB.ValuationDate }
                        cost: 50406.55
                        I/O estimate : [
                                rowcount=158985.8
                                averagewidth=14
                                pages=383.3457
                                prefetchpages=383.3457
                                lio=385.3457 pio=77.60534 cpu=476957.2
                                scanlio=385.3457 scanpio=77.60534 scancpu=476957.2
                                tempdb=0
                        Cache Strategy: [
                                prefetch=YES
                                iosize=131072 Bytes
                                bufreplace=LRU
                        order: none )
Now to understand what is happening, let's take the bad example:
select MID , max(Date) from CB where MID = @MID group by MID
Now, let's make it a bit more generic:
select type, count(*), max(crdate)
from sysobjects
where type='P'
group by type
If run in master on my machine, I get:
type                                            
P             20             Oct  2 2014 12:23PM
...as a result, with an initial LOP of:
The Lop tree:
( project
( group
  ( scan sysobjects
Which should be no surprise....with no index on type...or due to the quantity of rows in sysobjects, we simply go for a tablescan.   But we have our (group ) LOP.....and if we look at the plancost:
==================== Lava Operator Tree ====================
                                    Emit                   
                                    (VA = 3)               
                                    r:1 er:2               
                                    cpu: 0                 
                        Restrict                           
                        (0)(0)(0)(4)(0)                    
                        (VA = 2)                           
                        r:1 er:2                           
            GroupSorted                                    
            Grouping                                       
            (VA = 1)                                       
            r:1 er:2                                       
TableScan                                                  
sysobjects                                                 
(VA = 0)                                                   
r:20 er:19                                                 
l:8 el:8                                                   
p:0 ep:2                                                   
============================================================
We see sort of the same problem....we are estimating 2 rows to be returned from the group by. 
Stepping back a bit, remember, if we don't have any stats on a column, we assume 0.1 for =, 0.25 for bounded range (between) and 0.3 for unbounded range.   In my case, with no stats on type in sysobjects in master, we can see this clearly in the index selectivity area of:
The table (Datarows) has 188 rows, 6 pages,
Data Page Cluster Ratio 0.9999900
    type = 'P'
   Estimated selectivity for type,
        selectivity = 0.1,
    Search argument selectivity is 0.1.
    using table prefetch (size 32K I/O)
    Large IO selected: The number of leaf pages qualified is > MIN_PREFETCH pages
    in data cache 'default data cache' (cacheid 0) with LRU replacement
In the index selectivity due to using the magic values.   In the group by costing, we see:
( PopGroupSorted
  proj: {{ sysobjects.type Gtg0.Gc5 } ,{ Gtg0.Gc3 Gtg0._virtualagg Gtg0._virtualagg } ,{ Gtg0.Gc4 Gtg0._virtualagg Gtg0._virtualagg } }
  pred: [Tc{} Pe{{ sysobjects.type Gtg0.Gc5 }  = 'P'}]
  subs: {sysobjects.type ,Gtg0._virtualagg ,Gtg0._virtualagg }
  cost: 65.44175
  I/O estimate : [
   rowcount=1.88
   averagewidth=21
   pages=1
   prefetchpages=1
   lio=0 pio=0 cpu=18.8
   total lio=8 total pio=1.00007 total cpu=244.4
  Cache Strategy: [
   prefetch=YES
   iosize=4096 Bytes
   bufreplace=LRU
  order: none
  ( PopTabScan table: Gtt1( sysobjects )
   proj: {{ sysobjects.type Gtg0.Gc5 } ,{ sysobjects.crdate } }
   pred: [Tc{} Pe{{ sysobjects.type Gtg0.Gc5 }  = 'P'}]
   subs: {sysobjects.type ,sysobjects.crdate }
   cost: 63.56175
   I/O estimate : [
   rowcount=18.8
    averagewidth=12
    pages=8
    prefetchpages=8
    lio=8 pio=1.00007 cpu=225.6
    scanlio=8 scanpio=1.00007 scancpu=225.6
   Cache Strategy: [
    prefetch=YES
    iosize=32768 Bytes
    bufreplace=LRU
   order: none )
Now....to go from the row count to the estimated rows for a group by, we don't use the column selectivity - we use column density stats.  The real reason behind the 0.1 is that we are saying is that there likely is only 10 distinct values.   For example, if I update statistics sysobjects (type) in my system, the output changes to:
==================== Lava Operator Tree ====================
                                    Emit                   
                                    (VA = 3)               
                                    r:1 er:1               
                                    cpu: 0                 
                        Restrict                           
                        (0)(0)(0)(4)(0)                    
                        (VA = 2)                           
                        r:1 er:1                           
            GroupSorted                                    
            Grouping                                       
            (VA = 1)                                       
            r:1 er:1                                       
TableScan                                                  
sysobjects                                                 
(VA = 0)                                                   
r:20 er:21                                                 
l:8 el:8                                                   
p:0 ep:2                                                   
============================================================
Which is based on:
( PopGroupSorted
  proj: {{ sysobjects.type Gtg0.Gc5 } ,{ Gtg0.Gc3 Gtg0._virtualagg Gtg0._virtualagg } ,{ Gtg0.Gc4 Gtg0._virtualagg Gtg0._virtualagg } }
  pred: [Tc{} Pe{{ sysobjects.type Gtg0.Gc5 }  = 'P'}]
  subs: {sysobjects.type ,Gtg0._virtualagg ,Gtg0._virtualagg }
  cost: 65.80175
  I/O estimate : [
   rowcount=1
   averagewidth=21
   pages=1
   prefetchpages=1
   lio=0 pio=0 cpu=20
   total lio=8 total pio=1.00007 total cpu=248
  Cache Strategy: [
   prefetch=YES
   iosize=4096 Bytes
   bufreplace=LRU
  order: none
  ( PopTabScan table: Gtt1( sysobjects )
   proj: {{ sysobjects.type Gtg0.Gc5 } ,{ sysobjects.crdate } }
   pred: [Tc{} Pe{{ sysobjects.type Gtg0.Gc5 }  = 'P'}]
   subs: {sysobjects.type ,sysobjects.crdate }
   cost: 63.80175
   I/O estimate : [
    rowcount=20
    averagewidth=12
    pages=8
    prefetchpages=8
    lio=8 pio=1.00007 cpu=228
    scanlio=8 scanpio=1.00007 scancpu=228
Note that my overall rowcount went up a bit....but the group by went to 1 row....if we look at the column stats via optdiag:
Statistics for column:                                                          "type"
Last update of column statistics:                                               Feb 15 2015  9:18:32:850PM
     Range cell density:                                                        0.0053191489361702
    Total density:                                                             0.4216274332277049
     Range selectivity:                                                         default used (0.33)
     In between selectivity:                                                    default used (0.25)
     Unique range values:                                                       0.0053191489361702
     Unique total values:                                                       0.2000000000000000
     Average column width:                                                      default used (2.00)
     Rows scanned:                                                              188.0000000000000000
     Statistics version:                                                        4
Histogram for column:                                                           "type"
Column datatype:                                                                char(2)
Requested step count:                                                           20
Actual step count:                                                              9
Sampling Percent:                                                               0
Tuning Factor:                                                                  20
Out of range Histogram Adjustment is DEFAULT.                                  
Low Domain Hashing.                                                            
     Step     Weight                    Value
        1     0.00000000       <=       "EJ"
        2     0.00531915        <       "P "
        3     0.10638298        =       "P "
        4     0.00000000        <       "S "
        5     0.30319148        =       "S "
        6     0.00000000        <       "U "
        7     0.56382978        =       "U "
        8     0.00000000        <       "V "
        9     0.02127660        =       "V "
....so the 20 rows are due to the slightly higher 0.10638 vs. 0.1...
Now....if we know the value for the where clause and have stats on the column, I notice we always estimate 1 row to be returned from the group by.   However, if we don't have stats - or if we don't know the value - we estimate more than one row.   For example if I declare @var for type ala:
declare @type char(2)
select @type='P'
select type, max(crdate)
from sysobjects
where type=@type
group by type
go
I then get:
( PopGroupSorted
  proj: {{ sysobjects.type Gtg0.Gc4 } ,{ Gtg0.Gc3 Gtg0._virtualagg Gtg0._virtualagg } }
  pred: [Tc{} Pe{{ sysobjects.type Gtg0.Gc4 }  = '}]
  subs: {sysobjects.type ,Gtg0._virtualagg }
  cost: 83.58154
  I/O estimate : [
  rowcount=4.17777
   averagewidth=17
   pages=1
   prefetchpages=1
   lio=0 pio=0 cpu=79.26596
   total lio=8 total pio=1.00007 total cpu=425.7979
...if we have stats on type vs. the 1.88 when we don't.   Which points out that the uniqueness stats and selectivity are likely considered in the final cost of the group by.   In your case, the estimate of:
                I/O estimate : [
                        rowcount=7.388771
                        averagewidth=19
                        pages=1
                        prefetchpages=1
                        lio=0 pio=0 cpu=158985.8
                        total lio=385.3457 total pio=77.60534 total cpu=635943
                        tempdb=0
...is likely due to the column uniqueness and selectivity stats based on the @MID variable
Note that despite we now know the GROUP BY is only going to return a single row, we still don't change the plan.....we still hit the index in ascending fashion.   The reason why is that we don't assume (or should I say we don't make a special case) that the only aggregate is a max().   It could be count(), avg(), min() or a combination of which - any of could require reading every index row other than strictly min().   Could we do so??  Possibly.....however, arguable, the select max() without the group by is the more correct SQL to use....   We do (on the other hand) have special processing for scalaragg with max() as it does the backwards scan if max() is the only aggregate....if you do select min(), max() - then it does a forward scan even with scalaragg.   If you have just min(), we do a forward scan and short circuit after first row (as if select top 1)....