• aliceif (disco)
    Comment held for moderation.
  • VinDuv (disco)
    Comment held for moderation.
  • PJH (disco) in reply to aliceif

    Done.

  • aliceif (disco) in reply to VinDuv

    Maybe it is C and C++ but written Java-style? It's the only language not in quotes ...

  • accalia (disco)

    /facepalm

    Threading is hard to begin with, threading while communicating with a database is..... /double_facepalm

  • balazs (disco)

    Another WTF in the same post:

    class StreetQuery implements Thread {
    

    Thread is a class, not an interface, so you implement the Runnable interface or extend the Thread class which implements Runnable. Then you can start the execution with calling an appropriate start method like new Thread(new StreetQuery()).start(); or just call it if you extended your class from Thread.

  • Steve_The_Cynic (disco)

    Nobody has yet commented on the clear implication in the code of normalisation run wild. It's implied that they have a "street" table in which some sort of city ID is a foreign key referencing the "city" table, which in turn has a foreign key referencing the "state" table etc.

    And no, not all addresses (in the real world) have provinces. Even in countries that have some sort of equivalent of provinces (e.g. France, where there are four main administrative levels: commune, département, région, and the whole of France) those provinces aren't necessarily used in people's addresses (e.g. France, where an address would normally be 123 rue Quelque Chose, DDNNN Nom-de-Ville, France - and nothing more than that - DDNNN is the post code, two digits for the département and three to identify the commune within the département. The name of the département and région aren't used.).

  • Arantor (disco)

    Is it now a thing that we have to link to our own memes in stories?

  • Steve_The_Cynic (disco) in reply to Arantor
    Arantor:
    Is it now a thing that we have to link to our own memes in stories?
    Are you saying you want an automatic doodad that detects and links to memes??/
  • Arantor (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    Are you saying you want an automatic doodad that detects and links to memes??/

    No, I'm saying that this article uses brillance, and links to the relevant TDWTF story and I see no need for this to even be a thing.

  • Steve_The_Cynic (disco) in reply to Arantor
    Arantor:
    No, I'm saying that this article uses brillance, and links to the relevant TDWTF story and I *see no need for this to even be a thing.*
    I think that's a Discourse bug - a topic doesn't exist and can't be linked to unless it has at least one post. Unless they add the post and then hide / delete / etc. it, there has to be a visible post at the top. Like most of Discourse, it's lame, but hey, it's Discourse, so it must suck.
  • Jaloopa (disco) in reply to Arantor
    Comment held for moderation.
  • aliceif (disco) in reply to Jaloopa
    Comment held for moderation.
  • Arantor (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    I think that's a Discourse bug - a topic doesn't exist and can't be linked to unless it has at least one post. Unless they add the post and then hide / delete / etc. it, there has to be a visible post at the top. Like most of Discourse, it's lame, but hey, it's Discourse, so it must suck.

    No, no, that's not what I mean.

    This article, on the main site, links the word 'brillance' to the Paula Bean article of old.

    I see no reason for this to be a thing.

  • Steve_The_Cynic (disco) in reply to Arantor
    Comment held for moderation.
  • Arantor (disco) in reply to Steve_The_Cynic
    Comment held for moderation.
  • kupfernigk (disco) in reply to accalia

    "Threading while using a database" How do you think we code servers? The wtf is multithreading an atomic query. But I wonder if they got the idea from Hibernate?

  • accalia (disco) in reply to kupfernigk

    multithreading multiple requests from multiple sources for a server = good

    multithreading multiple requests from the same source with the same WHERE/JOIN/GROUP clauses and selecting different columns = /triple_facepalm

  • chubertdev (disco)

    FullAddress NVARCHAR(MAX)

  • JoeCool (disco) in reply to Arantor
    Arantor:
    Well, yeah, but this is what I mean... why is this a thing now? Or is it something that has been a thing forever and I just never noticed?

    maybe it is "you must be new here" post prevention.

  • Arantor (disco) in reply to JoeCool
    JoeCool:
    maybe it is "you must be new here" post prevention.

    B-b-b-but that's sport around these parts!

  • some_damn_yank (disco) in reply to aliceif
    aliceif:
    **F**TFY

    FTFY

  • chubertdev (disco) in reply to some_damn_yank
    Comment held for moderation.
  • aliceif (disco) in reply to some_damn_yank

    No, I just discofied it. Which is the opposite of fixing.

  • mihi (disco)

    TRWTF is the busy wait loop, of course. Unless you have more cores than active threads, busy waiting is always bad for performance. Add a simple Thread.yield() in there, and it will be suddenly a lot faster while using less resources :)

  • xaade (disco) in reply to Arantor
    Comment held for moderation.
  • FrostCat (disco) in reply to xaade
    xaade:
    So, now we are going to turn into this

    I suspect only until the authors get bored of it. That's actually pretty tedious to do, speaking as someone who occasionally does it.

  • aliceif (disco) in reply to FrostCat

    Can't be more tedious than adding Cornify tags ...

  • chubertdev (disco)

    I like how the link on the "main" comment preview page links to post #127191, which I assume is meant to go to the end.

    Who wants to get this thread above 128k posts?

  • LurkerAbove (disco) in reply to chubertdev

    Maybe suggest that turning off UAC is good or start giving out free likes.

  • accalia (disco) in reply to chubertdev
    Comment held for moderation.
  • chubertdev (disco) in reply to accalia
    Comment held for moderation.
  • accalia (disco) in reply to chubertdev

    hmm...

    remind me tonight i'll fork and submit one.

    we don't want to get alex upset by trying to game the system more than usual and having it leak onto the front page.

  • accalia (disco) in reply to accalia

    huh... the number 127191 doesn't appear in source....

    where did it come from then?

  • chubertdev (disco) in reply to accalia

    124774 on the previous day.

    I don't get it.

  • accalia (disco) in reply to chubertdev

    theory. it's using MAX(post_id) for that value when it generates the link.

    don't have time to look more thoroughly right now i'll do that tonight.

  • chubertdev (disco) in reply to accalia

    .............uggh.

  • kupfernigk (disco) in reply to accalia
    accalia:
    multithreading multiple requests from the same source with the same WHERE/JOIN/GROUP clauses and selecting different columns = /triple_facepalm

    That's what I said, I just used fewer words to do it.

  • accalia (disco) in reply to kupfernigk

    yes, but i actually had to borrow a co-worker's hand to get the triple facepalm.

  • chubertdev (disco)

    Lines 15-18 of ViewCommentsViewModel.cs:

                if (this.MaxDiscoursePostId > 0)
                    this.DiscourseTopicUrl = this.Article.DiscourseThreadUrl + "/" + this.MaxDiscoursePostId;
                else
                    this.DiscourseTopicUrl = this.Article.DiscourseThreadUrl;
    

    Set on line 14 of ViewCommentsViewModel.cs:

    this.MaxDiscoursePostId = this.Comments.Any() ? this.Comments.Max(c => c.DiscoursePostId ?? 0) : 0;

  • accalia (disco) in reply to chubertdev

    you want to make the pull request since you have the code in front of you?

    just replace the whole lot with:

    this.DiscourseTopicUrl = this.Article.DiscourseThreadUrl + "/last";
    
  • chubertdev (disco) in reply to accalia

    I just had a flash flood at work. Maybe a year from now, haha.

  • accalia (disco) in reply to chubertdev

    fair enough.

  • accalia (disco) in reply to chubertdev
    Comment held for moderation.
  • MRAholeDBA (disco)

    Breaking up the query into multiple queries can cause issues with bad results depending on your isolation level. For example if you have read committed isolation level (default in SQL Server, not in Oracle), it could be that the first query does get the proper data, then before the next select can run a update is ran against the field, and now the query that returns the 2nd column in the same row has different data. Isolation levels are rarely thought of except by developers who have DBA experience or have been hit by it in the past, so just watch out for that.

    SQL Server handles parallelism pretty well and has a threshold you can set to see how strongly it should try to do it for you, but I'd recommend having an experienced DBA help you figure it out as it's part art and part science which involves knowing the code base well, which queries are really important, and a few other variables such as certain CPU wait times correlating against cxpackets (A cxpacket wait type will not tell you if there is an issue, it'll just tell if you if parallelism is working, typically you need several baselines, execution plans, wait_stats looking, and perhaps SOS_Scheduler_Yield and some other metric I forgot that's like "C2 CPU" in PerfMon).

    SQL 2005+ Enterprise Edition ($$$) handles parallelism using a 'Advance Scanning' mechanism and keeping the data in memory to be used with another query that has a current execution plan and is executing using a full table scan. This avoids cases where bad indexes or statistics can stop the index from being used and we have to scan the full table.

    I'm not sure what the dev who did this was thinking. Perhaps he was a MySQL Developer who is used to the non ACID compliance in the MyISAM data table instead of the INNODB table type. Odd. Otherwise I have no idea why they would think this is a good idea. Why didn't they even test this before trying it? O.o

    Edit: Even moar edits! This makes even less sense now that I thought about it for a few mins. A "Bookmark Lookup" operation in SQL is very expensive, that's when you're using a non clustered index to gather some of the data, but the remaining data is in the base table. SQL Server will then try to get all the data from the index, and get the rest from the base table by identifying the row. If it takes too long to do that, it'll just do a full table scan where the Enterprise Edition table scan sharing would be helpful. If he was having bookmark lookups, why not just put the columns in the proper index? If not, then why force this parallelism across the same table when the scan has to read the index anyways??

    I'm going to go have a drink I think.

  • chubertdev (disco) in reply to accalia
    accalia:
    fair enough.

    Only lasted 3 hours. Now it's just a huge pile of work, but no fires.

  • chubertdev (disco) in reply to accalia

    The other thing I was wondering was if it was the most recent post in the thread, or the last one that the specific user had read...

  • accalia (disco) in reply to chubertdev

    not entirely sure. would be more useful if the later.

  • chubertdev (disco) in reply to accalia
    Comment held for moderation.
  • redwizard (disco) in reply to accalia
    accalia:
    /double_facepalm

    I did that too when I read the parallel threading bit.

Leave a comment on “Parallel SQL Queries”

Log In or post as a guest

Replying to comment #:

« Return to Article