Common Table Expressions

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » T-SQL (SS2K5) » Common Table Expressions

16 posts, Page 2 of 2

««1 2

Common Table Expressions

Rate Topic

Display Mode

Topic Options

Author

Message

Lynn Pettis

Posted Wednesday, December 09, 2009 7:17 AM

SSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 11:07 PM
Points: 21,625, Visits: 27,468

BaldingLoopMan (12/9/2009)

All very useful info guys. Once again it appears the geniuses at sql server have designed a new way to do the same thing but w/ different syntax. Sure there are some minor performance gains as usual. Sorry for the disgruntled attitude. The gators lost, I just got in, and haven’t finished my coffee. Also I just ate about 2 lbs of bacon at an all u can eat breakfast buffet. Bacon is my weakness and I’m paying for it now.

Personally i develop using the #tables then convert them to @tables where needed when moving my code to prod. I like the #tables in development because i can see what is in them after the process runs and so on. It's essential to the dev process.

Perhaps i will start to integrate these CTE's going forward and be a good boy.

Be careful using table variables. Since they do not have statistics, the Query Optimizer assumes that table variables always have 1 row regardless of actual number of rows. For a table variable with a few hundred rows, not bad, but when you get to thousands and more you won't get an optimal execution plan for the query.

Cool

Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)

Post #831391

BaldingLoopMan

Posted Wednesday, December 09, 2009 7:23 AM

Old Hand

Group: General Forum Members
Last Login: Wednesday, December 05, 2012 7:23 AM
Points: 304, Visits: 457

Are u saying if i'm using a #table and it has 10,000 recs then the optimizer may not optimize properly? Interesting. Would it by using the CTE w/ 10,000 recs?

Post #831396

Lynn Pettis

Posted Wednesday, December 09, 2009 7:28 AM

SSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 11:07 PM
Points: 21,625, Visits: 27,468

BaldingLoopMan (12/9/2009)

Are u saying if i'm using a #table and it has 10,000 recs then the optimizer may not optimize properly? Interesting. Would it by using the CTE w/ 10,000 recs?

No, #tables have statistics so the QO will know that the table has 10,000 records. An @table with 10,000 records, however, will be treated by the QO as if it had only 1 row. This may result in a less than optimal execution plan for the query.

Cool

Lynn Pettis

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)

Post #831400

Garadin

Posted Wednesday, December 09, 2009 7:28 AM

SSCommitted

Group: General Forum Members
Last Login: Wednesday, November 07, 2012 4:08 PM
Points: 1,525, Visits: 4,047

BaldingLoopMan (12/9/2009)

You can see what is in a CTE as well, just SELECT * from it. I'm actually intending to write an article on temp tables and how they're not evil... but they're not always applicable either. Derived tables / CTE's can provide a marked performance increase over temp tables / table variables *in some cases*. Every situation is different, and CTE's (or derived tables) definitely have their place.

Seth Phelabaum

Consistency is only a virtue if you're not a screwup. Wink

Links: How to Post Sample Data :: Running Totals :: Tally Table :: Cross Tabs/Pivots :: String Concatenation

Post #831402

BaldingLoopMan

Posted Wednesday, December 09, 2009 7:41 AM

Old Hand

Group: General Forum Members
Last Login: Wednesday, December 05, 2012 7:23 AM
Points: 304, Visits: 457

not sure what ur saying about the selecting for a cte because u can sdo that w/ the #tables as well.

However that is very interesting the the QO will look at a @table w/ n records and take it as having 1 record. That explains some search optimization i was doing years ago that wouldn't play nice.

Post #831412

Garadin

Posted Wednesday, December 09, 2009 7:49 AM

SSCommitted

Group: General Forum Members
Last Login: Wednesday, November 07, 2012 4:08 PM
Points: 1,525, Visits: 4,047

BaldingLoopMan (12/9/2009)

not sure what ur saying about the selecting for a cte because u can sdo that w/ the #tables as well.

I like the #tables in development because i can see what is in them after the process runs and so on

Right, I was just saying that you could do the same with CTE's, not that you COULDN'T do it with temp tables. The way your statement read, it seemed like you were arguing that as a reason to use temp tables instead of CTE's.

Granted, because of the single query limitations of CTE's, you can't do 20 different operations to them and then view them as easily as you could a temp table (although CTE's can refer to any cte above them, so you can do multiple operations to them, but then you start getting into areas where temp tables might be better), so they're not always as easy to deal with. That said, a programming method should not be chosen just because it is easier, especially in SQL.

Seth Phelabaum

Consistency is only a virtue if you're not a screwup. Wink

Links: How to Post Sample Data :: Running Totals :: Tally Table :: Cross Tabs/Pivots :: String Concatenation

Post #831418

« Prev Topic | Next Topic »

16 posts, Page 2 of 2

««1 2

Permissions