SQL Statement

  • Dang, while being in Portugal I was able to watch "The life of Brian" in english. I watched it 4x during that weekend. I love it, though I must admit that strangely the German synchronisation did a good job. Off-topic?!?

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Only slightly.

    But the person posting the original thread hasn't come back with any form of reply - no feedback or answers to the questions raised.

    So, it's only fair that whilst checking for a reply - we at least amuse ourselves.....

    Life of Brian - excellent. Do the dvd subtitles in different languages not do films justice? Being ignorant and only fluent in one language I really have no idea.....

    The Holy Grail, even better......

    Have fun

    Steve

    We need men who can dream of things that never were.

  • Well its Christmas so surely its as good a time as any to contemplate the "Meaning of life"?

    I've got the "Monty Python Sings" CD in my lap-top for when the political correctness gets too ridiculous.  I've currently got "Never be rude to an arab" coming through my head phones".

  • I must confess, that I have my problem with the language. If I hadn't had the German synchronisation in the back, I would have been lost at times. I guess Monty Python doesn't qualify for BBC english.

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Called, some one did, hm?

    The path to becoming a jedi is made possible by using clear, precise logic in your code.

    A WHERE clause with join criteria and filters-- long it will become, hmm?

    Should the path of simplicity and clarity exists, take it you should! A path to harnessing the power of the force!

    Left outer joins, not easily and quickly comprehended as *= , hm? A true jedi will use the tools at his disposil to make his code shorter and easier to understand, assuming performance is a constant.

    To do otherwise leads to the dark side!

  • Dude I am a geek but you have wwwwwwwwwwwwwaaaaaaaaaaaaaaaaaaaaaayyyyyyyyyyyyyyyy to much time on your hands.

  • also a [no lock] would speed things up

  • Steve,

    Regarding your question "why a query with INNER JOIN-s may perform worse than the equivalent query with WHERE conditions": this is theoretically possible (although in very rare circumstances), because of the order of evaluation of the conditions. The query optimizer should try to use many combinations of ordering, but it doesn't try all of them.

    First thing, to diagnose this further, you should make sure that your statistics are up to date (run an sp_updatestats to be sure).

    Second, try to compare the execution plan of the two queries without the TOP 50 clause.

    Third, try to rewrite the query with INNER JOIN-s by specifying the tables in a different order.

    Razvan

Viewing 8 posts - 16 through 22 (of 22 total)

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