Neat trick on the UPDATE columns and variables at same time. Never seen that before.
@ErikDarlingData
3 ай бұрын
Yeah! The first time I saw that done my brain well full scrambled eggs.
@jleiser22
3 ай бұрын
I've seen where you update the column value and the variable at the same time but never where you simply assign the variable to the column being updated. Now I'll be looking for a way to implement this nugget of wisdom. Totally worth the price of subscribing to this channel :)
@ErikDarlingData
3 ай бұрын
@@jleiser22 woohoo! Yeah, let me know if you find any good uses for it.
@miguelcastillo7346
3 ай бұрын
Thanks for the masterclass greetings from Nicaragua.
@ErikDarlingData
3 ай бұрын
Hello and welcome!
@drivetrainerYT
3 ай бұрын
utility^fun channel, thx a lot
@mattcargile
2 ай бұрын
Economics and queues!! 😊
@ErikDarlingData
2 ай бұрын
Equeuenomics?
@PeterSchott
2 ай бұрын
Not quite sure how you really feel about pessimistic locking.... But we did use something similar to this to a queue that worked pretty well for us many years ago - very similar lock patterns and all. Took a bit to work it out at the beginning and test it all, but once in place it was great.
@ErikDarlingData
2 ай бұрын
Yeah! Getting this stuff working is such a cool challenge.
@clerincg
2 ай бұрын
Hey Eric. Great post! I learned a lot :) I'm working with my developers on Index Cardinality. I noticed that you used [in_process] (BIT) as the first column in your Clustered Index. I get it that the zero values will be MUCH fewer than the 1 values, so that's a high performance index even with a low cardinality field as the first field in the Composite Key. My question is, would you consider creating the Clustered Index JUST on [id] and then creating a non-clustered Filtered Index with a [WHERE (in_process = 0)] predicate and INCLUDE [id]. That would satisfy my preaching cardinality in Composite Keys, but would it still be high performance? I appreciate you!!!
@ErikDarlingData
2 ай бұрын
That over complicates locking because now there are two indexes to maintain.
@BalajiRam-e2c
3 ай бұрын
Can you explain a bit about why UPDLOCK is necessary and how it helps? I remember seeing some blog in the past where UPDLOCK hint is used in update statement as well... Also more about ReadCommitted hint if you can. Thanks!
@ErikDarlingData
3 ай бұрын
Because it takes an exclusive lock, and along with the other hints ensures that no other workers attempt to process that row.
@DanielMaenle
3 ай бұрын
Never heard of Fafo. What queuing type is that?!? 😂
@ErikDarlingData
3 ай бұрын
You’ll know when you try it!
@Loticx
3 ай бұрын
Are there pros/cons on this method over using service broker?
@ErikDarlingData
3 ай бұрын
Yes, using service broker is a con.
@FlaggedStar
3 ай бұрын
@@ErikDarlingData Where can I learn more about it being a con? I only ever see it already turned on. I've never seen it come up in a tutorial, guide, or a book. I could read the official docs, but they won't tell me why it's a con.
@GroterRonald
3 ай бұрын
Should parameter @id not be an bigint?
@ErikDarlingData
3 ай бұрын
In this case, no. None of the columns in the StackOverflow database are bigint.
@FlaggedStar
3 ай бұрын
03:05 I'm confused. If you think it's laughable to worry about the extra four bytes for a big int, why do all of your examples page-compress the indexes? I'm not trying to be clever here. I'm quite honestly confused.
@ErikDarlingData
3 ай бұрын
I’m not sure why you’re confused. There’s no dichotomy here. Page compression is a generally good thing and using bigint when you might run out of regular integers is a good thing. Seems like you could extend those examples to do two good things.
@douglascoats7081
3 ай бұрын
kind of sad you really didnt delve into the fafo method. Us plebs really wanna know how you handle that lol
@ErikDarlingData
3 ай бұрын
I don’t.
@dforck42
2 ай бұрын
tsk tsk, didn't even start the bigint at the max negative value ;-)
@ErikDarlingData
2 ай бұрын
You’re a monster.
@dforck42
2 ай бұрын
@@ErikDarlingData yes, but double the numbers!
@Finezzato
2 ай бұрын
you've got to be fucking kidding me dude, almost everyone's working on the default sql server row locking
Пікірлер: 31