Table Access Order

Question

Table Access Order

Viewing 5 posts - 31 through 34 (of 34 total)

You must be logged in to reply to this topic. Login to reply

Andre Guerreiro SSCertifiable Points: 7319 More actions · Answer 1

SQL Kiwi (9/23/2011)Adam (Machanic) would no doubt want me to encourage you to share a link to SQLblog instead (traffic = advertising = pays the hosting bills) but I understand that is not always possible.

I'm currently starting a new SQL blog(it's very basic now and in Portugues) and I'll be adding links to your blog, Paul Randall's, Kimberly Tripp's, GilaMonster's and others if that's ok.

It's sad that some people will copy an article reinventing the wheel and stealing the credit instead of sending the reader to the right place and giving credits to those who are due.

I'm just a learner. 😀

Best regards,

Andre Guerreiro Neto

Database Analyst
http://www.softplan.com.br
MCITPx1/MCTSx2/MCSE/MCSA

Paul White SSC Guru Points: 150467 More actions · Answer 2

codebyo (9/24/2011)
I'm currently starting a new SQL blog(it's very basic now and in Portugues)...

Looks good! I am also a fan of Fabiano Amorim by the way.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

spaghettidba SSC Guru Points: 105732 More actions · Answer 3

Great question, Paul!

I got it wrong, as usual. 🙂

I was highly tempted to pick the correct answer based on how the hash operator works, but I suspected there was a "trick" somewhere and I didn't listen to my brain.

Anyway, I have a doubt and I'm sure you can clear things up.

Here's a small test I ran:

SET STATISTICS IO ON

-- Changed to temp tables in order to recognize the table names

-- in STATISTICS IO output

CREATE TABLE #A (a INT NOT NULL)

CREATE TABLE #B (b INT NOT NULL)

SELECT COUNT_BIG(*)

FROM #A

LEFT HASH JOIN #B ON [#B].b = [#A].a

SELECT COUNT_BIG(*)

FROM #A

RIGHT HASH JOIN #B ON [#B].b = [#A].a

Output:

Warning: The join order has been enforced because a local join hint is used.

--------------------

0

(1 row(s) affected)

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#A__000000024106'. Scan count 1, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Warning: The join order has been enforced because a local join hint is used.

--------------------

0

(1 row(s) affected)

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#B__000000024107'. Scan count 1, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#A__000000024106'. Scan count 1, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

As you can see, in this case STATISTICS IO returns objects in reverse order. Is this sensible and/or guaranteed/documented?

I couldn't find anything on the subject.

-- Gianluca Sartori

Paul White SSC Guru Points: 150467 More actions · Answer 4

Gianluca Sartori (9/30/2011)
As you can see, in this case STATISTICS IO returns objects in reverse order. Is this sensible and/or guaranteed/documented? I couldn't find anything on the subject.

I don't know the answer to that; however I'm pretty sure it isn't documented or guaranteed.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

spaghettidba SSC Guru Points: 105732 More actions · Answer 5

SQL Kiwi (9/30/2011)
Gianluca Sartori (9/30/2011)
As you can see, in this case STATISTICS IO returns objects in reverse order. Is this sensible and/or guaranteed/documented? I couldn't find anything on the subject.
I don't know the answer to that; however I'm pretty sure it isn't documented or guaranteed.

Thank you, Paul.

I did a couple of tests and turns out that it was just a coincidence. Well, not entirely: the order of the tables in the STATISTICS IO output is often very similar to the execution order in the query plan, but it starts diverging when tables are accessed more than once, or parallelism kicks in, or... many other things.

-- Gianluca Sartori