• Ben Curthoys (unregistered)

    That SQL Server one isn't a WTF.

    The reason it shows you the estimated and actual number of rows is so that you can debug why and where the query analyser gets it wrong, and it gets it wrong usually because you've done something wrong in the database: either you aren't keeping index and table statistics up to date, or you've written a query which can affect wildly different numbers of rows depending on the input parameters and then let it cache the query plan, or similar.

    The query analyser is very good but it's not magic, and if it gets it wrong it's your fault, not Microsoft's.

    Also, it's not SSMS doing the estimating. It's Sql Server itself, because in order to run a query it needs to work out HOW to run the query, which indexes to use, which order to join tables, etc., and it's those estimates that help it work out the right answer to that question.

  • Anonymous (unregistered)

    Estimated comment count: 1

  • m (unregistered)

    Ah, good old If iDays < 10 Then sDays = "0" & Str(iDays) Else sDays = Str(iDays) EndIf. (Yes, wedevs don't use vb6 (I hope), it's just my preferred language for WTF code)

  • Peter (unregistered)

    I'm not sure how you could even read the countdown clock. The red/aqua is giving me a headache. Need more coffee!

  • Letchprecaun (unregistered)

    Sesstion? Good thing Python isn't interpreted, and that it's type-safe....

  • Si (unregistered)

    The SQL Server thing isn't really a WTF. Either the query's a bit bunk, the statistics are monumentally stale or there's a table variable at play (money on the latter).

  • RichP (unregistered)

    SQL management studio is using "The Price is Right" estimating rules. It concluded everyone else's estimates were way too large, so it bid 1 record. It wins because it got the closest without going over.

  • Little Bobby Tables (unregistered)

    Good grief, is it Friday already? I've spent the whole day thinking it's Thursday.

  • Jay A (unregistered) in reply to RichP

    Actually, from the Compute Scalar operator in the query plan, SQL Server itself will always estimate 1 row... The trick is getting that Compute Scalar out of the WHERE clause somehow...

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    The deal if the week code probably looks like this to try to format single-digit values as 2 digits:

    if (days < 10) {
    days_str = "0" + days;
} else {
    days_str = days;
}

    Give it an input of -2, get an output of "0-2".

  • Some Guesty (unregistered)

    Something about the "Zero Latency WOW!" tells me that the programmer knew handling such a result would require a "WOW"

  • (nodebb)

    Re the class not found one, my quession is...

  • eSyr (unregistered)

    What's the problem with zero millisecond latency (assuming that it's just a sub-millisecond one)? You just have to be within 150 kilometers (minus hw/sw stack latency) of the testing site.

  • anonymous (unregistered) in reply to eSyr

    That reminded me of the "500-mile email" story.

  • Leevi (unregistered)

    The countdown on Deal of the Week is a clearly from a scammy site with arbitrarily set time limit for the deal. 0-2 d 0-15 h 0-59 m 0-26 s so it was meant to set a random time between those values.

  • gx (unregistered)

    I don't see anything wrong with that zero latency thing either. It's perfectly possible bo be below 0,5 ms.

  • dr memals (unregistered)

    The Agile zero latency Wow appears to be agileict https://www.agileict.co.uk/internet/

    Here is the offending graphic, deep with in an overly orange PDF https://www.agileict.co.uk/AgileInternetApril2018.pdf

    now I need new retinas.

  • David Mårtensson (unregistered)

    Estimated number of rows is determined by saved statistics.

    Problem is that you need to enable regular recompute of statistics or this value will be based on the empty DB :)

    The reason you do not always have this on is that for a very large DB, recomputing statistics can cause performance issues so you probably like to schedule it during off hours.

    And for small DB's it usually do not matter very much.

  • David Mårtensson (unregistered) in reply to David Mårtensson

    On the other hand, bad statistics will cause the query planner to create bad plans that cause VERY big performance issues, so you should definitely run those statistics at some time.

    Especially since a bad plan can escalate the problem, a bad plan can cause an exponential increase of intermediate result rows while a good plan would run separate parallell queries and then merge them.

  • Barf4Eva (unregistered)

    Excellent answer... I thought it odd to dismiss this as simply a "quirky SSMS estimation issue". Blaming SSMS for things that are administrative issues just doesn't help anyone. But I can understand the OP's initial reaction. :)

  • (nodebb)

    .replaceAll("", "") seems to have timed out.

  • fa (unregistered) in reply to dr memals

    From the PDF: "Up to zero latency".. not bad, though I would prefer if they could guarantee -10 milliseconds.

Leave a comment on “Kind of...but not really”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article