> First of all, you need to change your mindset when it comes to Cassandra. We understand that it is a difficult thing to do when you are used to running old, monolithic relational databases which are not designed for true high availability.
Why some need to throw unrelated / untrue / harsh comments about other DBMS's in answers?
My goal is to check if lineId's value exists. If not, it has to be zero by default.
Here is my datas:
For example:
SELECT lineId from table_name WHERE lineId = 80
There is no lineId = 80, then I want to see that lineId = 0 records.
Thanks, sincerely :)
This particular problem is quite difficult to do if you want to do it in a single query, while avoiding an extra sort as well as avoiding any lookups on the second half of the query. I couldn't find any way to avoid that last issue.
Even if I add a dummy row in the middle of the union, the Merge Concatenation still pulls at least one row from each set.
I'm a francophone and a francophile - but that SQLpro appears to be a "trou d'uc"! He talks about PostGreSQL fundamentalists and (this is hilarious) postGreSQL ayatollahs!. Another gem - In short, with PostGreSQL the choice of collation is between plague and cholera âŚ. Nuff said!
Was literally about to say: I throw down the gauntlet. Who can get my query to only pull rows from the first half of the union? I'll play first: a dummy VALUES with two LEFT JOINs doesn't work dbfiddle.uk/AK_Hf67k
Your query I can't even imagine how you could do that without requiring a sort and I'm thinking pretty hard
IIRC George Carlin was narrator for Thomas the tank enginee. There are supercuts on youtube when they mix his narration with some of his not so kid-friendly standups
How does "all operations are online" coincide with your suggestion to "Uninstall Cassandra from ALL the nodes" for doing a rollback? — ypercubeáľá´š22 secs ago
@PaulWhite Not sure about this. Maybe COUNT(CASE WHEN lineId = 80 THEN 1 END) OVER () and WHERE Count80 = 0 OR lineId = 80?
I'd be interested to know the efficiency of using an aggregate like that.
Speaking of which, I can never work out if FIRST_VALUE... OVER (...ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) is faster or slower than FIRST_VALUE... OVER (...ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
If you have a lot of rows I should have said. Because it's aggregating them into a single giant nvarchar(max) and then splitting it back out using STRING_SPLIT.
@PaulWhite Also if you are reading all the rows for both halves that doesn't count either. You need to only read the 80 rows, then read the 0 rows only if no rows from the first half.
@ypercubeáľá´š Good point, that works as well as mine in the simple case. Do note though that it doesn't answer my problem: it will still read at least one row from the TOP in order to know when to stop.
The action 16 hours ago was I shut it down from SQL Server Configuration Manager from the local server console. I just did SHUTDOWN WITH NOWAIT; from SSMS and it shut down immediately. Previously to that, I couldn't see anything in the session DMVs that was waiting.
also not to backtrack too much, but my first kid loved thomas the tank engine. we actually just gave away about 50 of those toy train cars to another family since they're not really played with much anymore.
had an aquarium car that did a whole light up thing
quite a show
it seems like this search engine with no pinterest results idea has legs
This particular problem is quite difficult to do if you want to do it in a single query, while avoiding an extra sort as well as avoiding any lookups on the second half of the query. I couldn't find any way to avoid that last issue.
@Charlieface Well technically it's 'better' by not reading any rows from the 'second half of the query'.
Same difference I suppose. Point is: you just want to read the first side once, and not any of the rows on the second side. Imagine the two halves are both very complex or expensive derived tables, you want to avoid reading from them if not necessary.
Eg they have blocking hash joins. You want to avoid reading even a single row, otherwise the hash build phase will run
@ErikDarling And that has the extra cost of writing and reading them. To be honest, if I was faced with this problem I would normally just do two separate SELECT queries with a @@ROWCOUNT check in between. Someone asked me just a couple of days ago about this exact problem, which is why I got interested.
@SeanGallardy-MostlyRetired So are you doing the same work now, just in a different space, or has the role changed more than that? Feel free to email instead.
Honestly, it's really ugly right now. I left (for reasons) and then 2 weeks later a bunch of others left. If you look at my previous role, in the last 1 month, 43% of the team left with another 15% of the team waiting on offers.
Management in my old team was pretty bad, when 58% of your team leaves in a month you'd normally say, wow what's going on... but instead they just say, all these people are problems we got rid of.
"Sorted for E's & Wizz" is a song written and performed by the English band Pulp for their 1995 album Different Class. Based lyrically on a phrase that lead singer Jarvis Cocker overheard at a rave, the song features lyrics examining the hollow and artificial nature of drug culture. Because of its subject matter, the song sparked controversy in the UK, where several tabloids attacked the song.
"Sorted for E's & Wizz" was released as a double A-side single with "Mis-Shapes" in September 1995, and reached No. 2 in the UK Singles Chart as well as No. 6 in Ireland. It was Pulp's second successive No...
@PaulWhite Cracked it finally! I whittled down your batch mode query again and again, and eventually ended up back at row-mode. All you need to do is use an OUTER APPLY for the second half, and push the first half's lineId into a VALUES (this must be the first table in the FROM of the second half). This causes it to get a Startup Filter which means the whole branch doesn't run.
db<>fiddle is too hard to use on my phone. The logic seems right except for the case when no zero rows exist in the table but I'm not certain previous solutions handled that correctly either. Assuming correct means no rows returned. But yes the key is the startup filter.
The single row table is a useful simplification over the window function. I've used that before no idea why it didn't occur to me here. Blame Verace and his window functions perhaps
@Charlieface you are right of course that t1 is a derived table. Not sure about the second case. Why isn't the t1 (in the CROSS APPLY version) a derived table as well?
Also: you seem to imply that the terms subquery and derived table are disjoint. I was thinking along the terms that a derived table is a kind of subquery.
@ypercubeáľá´š Yes they are disjoint (or rather mutually exclusive). A subquery is a query that is logically executed once per row of the outer table. Whereas a derived table is not, it exists independently (in logical terms) from the outer table.
CROSS JOIN does not: the table you reference must stand on its own (must be independenly executable), that is what is termed a derived table.
But CROSS APPLY behaves similarly to a subquery (although it can return more than one column or row) as it is executed once per row of the outer table, so I think that's how you would classify it.
Subquery and derived table are often used interchangeably. Table expression is another. Personally, I don't think the distinction is clear or even important.
@ypercubeáľá´š What do you call a subquery that returns a scalar value in the SELECT clause though?
> Derived tables (also known as table subqueries) are defined in the FROM clause of an outer query.
Logically executed per outer row is just another way of saying correlated
A table expression or derived table can also be correlated or not
It's really not important
The documentation for APPLY also prefers derived table over subquery. The right side of an apply can be any table source even a function. I think it's a stretch to call that a subquery in the everyday sense
People also tend to say subquery to describe anything that looks like a query, but is not at the outermost scope
No doubt everyone has their own set of preferences on this
The issue as I recall was parallel startup filters still opening their child operators, which was by design. We did heaps of hairy stuff with % modulus and stuff to work around other issues