12

Is there a performance difference between the following 2 queries, and if so, then which one is better?:

    select 
    q.id, 
    q.name 
    from(
        select id, name, row_number over (partition by name order by id desc) as row_num
from table
    ) q
        where q.row_num = 1

versus

select
max(id) ,
name
from table
group by name

(The result set should be the same)

This is assuming that no indexes are set.

UPDATE: I tested this, and the group by was faster.

Marina
  • 3,222
  • 5
  • 25
  • 35
  • 2
    Just test it? Second query should be `group by name` I assume – Andomar Jun 27 '12 at 18:55
  • There are a lot of variables here - in most cases these should boil down to the roughly the same plan (depending on underlying indexes); well actually the most costly part of each plan should be the same. But *you* are actually in the best position to test which is faster, because you can run both queries on your hardware, against your schema, with your data, stats, etc. – Aaron Bertrand Jun 27 '12 at 19:04
  • You'd really need to test, you can use the SQL*Plus autotrace feature. But if this is a test question, with no other information, I'm picking the second one, figuring out the execution plan for that is pretty straightforward. With the analytic functions (as in the first query), it's not clear what shortcuts the optimizer can figure out, like whether row_number has to be assigned to every row before the predicate (row_num = 1) is applied, or whether there's a STOPKEY shortcut. Without seeing the autotrace output, I'd go with the second one. – spencer7593 Jun 27 '12 at 20:50

3 Answers3

6

I had a table of about 4.5M rows, and I wrote both a MAX with GROUP BY as well as a ROW_NUMBER solution and tested them both. The MAX requires two clustered scans of the table, one to aggregate, and a second to join to the rest of the columns whereas ROW_NUMBER only needed one. (Obviously one or both of these could be indexed to minimize IO, but the point is that GROUP BY requires two index scans.)

According to the optimizer, in my case the ROW_NUMBER is about 60% more efficient according to the subtree cost. And according to statistics IO, about 20% less CPU time. However, in real elapsed time, the ROW_NUMBER solution takes about 80% more real time. So the GROUP BY wins in my case.

This seems to match the other answers here.

Robert Sievers
  • 1,277
  • 10
  • 15
5

The group by should be faster. The row number has to assign a row to all rows in the table. It does this before filtering out the ones it doesn't want.

The second query is, by far, the better construct. In the first, you have to be sure that the columns in the partition clause match the columns that you want. More importantly, "group by" is a well-understood construct in SQL. I would also speculate that the group by might make better use of indexes, but that is speculation.

Gordon Linoff
  • 1,242,037
  • 58
  • 646
  • 786
2

I'd use the group by name.

Not much in it when the index is name, id DESC (Plan 1)

but if the index is declared as name, id ASC (Plan 2) then in 2008 I see the ROW_NUMBER version is unable to use this index and gets a sort operation whereas the GROUP BY is able to use a backwards index scan to avoid this.

You'd need to check the plans on your version of SQL Server and with your data and indexes to be sure.

Martin Smith
  • 438,706
  • 87
  • 741
  • 845