Reading SHOW_PLAN output

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • bbcworldtour@hotmail.com

    Reading SHOW_PLAN output

    (Pardon me for asking a very basic question. I have come back to SQL
    Server after five years of Oracle, and my memory is a tad rusty).

    I have a bit of SHOW_PLAN output that I believe that I understand, but
    I would appreciate your comments if I am wrong.

    I have a requirement to produce a list of the primay key values in a
    table along with the total count of rows:

    Given this table and contents:

    create table taCountDemo (ID char(01) primary key, someData
    varchar(50));

    insert into taCountDemo (ID,somedata)
    select 'a', 'aaaa'
    union
    select 'b', 'bbbb';

    the results should be:

    ID counter
    ---- -----------
    a 2
    b 2

    (don't wonder why - there's a SAS application on top which means that
    ordinary rules of logic don't apply)

    This is the query that I'm using:

    select ID
    , cnt.counter
    from taCountDemo
    cross join
    (select counter
    from ( select count(*) as counter
    from taCountDemo
    ) as i
    ) as cnt;

    The SHOW_PLAN output is like this:

    |--Nested Loops(Inner Join)
    |--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLIC IT(int,
    [Expr1009],0)))
    | |--Stream Aggregate(DEFIN E:([Expr1009]=Count(*)))
    | |--Clustered Index Scan(OBJECT:([master].[dbo].
    [taCountDemo]. )
    |--Clustered Index Scan(OBJECT:([master].[dbo].
    [taCountDemo].)

    My understanding of this is that the count(*) is only executed ONCE,
    and that the nested loop then combines the result (EXPR1006) with all
    keys obtained by scanning the primary key index. Or in other words
    that the single-"row" result of the count(*) is chosen as the "table"
    that drives the loop.

    Is that correctly understood?

    Thanks for your input

    Bo Brunsgaard

  • Marcin A. Guzowski

    #2
    Re: Reading SHOW_PLAN output

    bbcworldtour@ho tmail.com wrote:
    (Pardon me for asking a very basic question. I have come back to SQL
    Server after five years of Oracle, and my memory is a tad rusty).
    >
    I have a bit of SHOW_PLAN output that I believe that I understand, but
    I would appreciate your comments if I am wrong.
    >
    I have a requirement to produce a list of the primay key values in a
    table along with the total count of rows:
    >
    Given this table and contents:
    (..)
    (don't wonder why - there's a SAS application on top which means that
    ordinary rules of logic don't apply)
    This is the query that I'm using:
    >
    select ID
    , cnt.counter
    from taCountDemo
    cross join
    (select counter
    from ( select count(*) as counter
    from taCountDemo
    ) as i
    ) as cnt;

    What about:

    SELECT ID, (SELECT Count(*) FROM taCountDemo) as counter
    FROM taCountDemo

    ?

    Execution plan will be exactly the same but IMHO it looks much simpler.

    The SHOW_PLAN output is like this:
    >
    |--Nested Loops(Inner Join)
    |--Compute Scalar(DEFINE:([Expr1006]=CONVERT_IMPLIC IT(int,
    [Expr1009],0)))
    | |--Stream Aggregate(DEFIN E:([Expr1009]=Count(*)))
    | |--Clustered Index Scan(OBJECT:([master].[dbo].
    [taCountDemo]. )
    |--Clustered Index Scan(OBJECT:([master].[dbo].
    [taCountDemo].)
    >
    My understanding of this is that the count(*) is only executed ONCE,
    and that the nested loop then combines the result (EXPR1006) with all
    keys obtained by scanning the primary key index. Or in other words
    that the single-"row" result of the count(*) is chosen as the "table"
    that drives the loop.
    >
    Is that correctly understood?

    Yes, you're completely right.


    --
    Best regards,
    Marcin Guzowski

    Comment

    • SB

      #3
      Re: Reading SHOW_PLAN output

      My understanding of this is that the count(*) is only executed ONCE,
      and that the nested loop then combines the result (EXPR1006) with all
      keys obtained by scanning the primary key index. Or in other words
      that the single-"row" result of the count(*) is chosen as the "table"
      that drives the loop.
      Maybe I am wrong but I think it is other way around. It puts the sql
      statement in a nested loop and count(*) is executed many times.

      Comment

      Working...