@J.D. regarding that estimate you have "That's because B-Tree's have an O(log(n)) search time complexity. That means if your table has 1 billion rows, in the worst case, it would take log2(1 billion) = 40 to find any subset of the data. If that table grew to 1 trillion rows, log2(1 trillion) = 50 to find any subset."
I believe the branching factor of b-tree indexes in most DBMS is even higher, so the numbers (40, 50) are even lower. I can't remember where I read it (might some article from the "Queen of Indexing") that common b-tree levels for tables with billions+ rows are between 5 and 8.
@ypercubeᵀᴹ Correct, that's why I always qualify my statements around B-Trees with "in the worst case", nowadays. You'll notice when I talk about the generic search time complexity, I don't apply a base # to the log function, as to your point, the branching / fan-out factor usually results in even better performance in practice. But then when I give an example after, I use base 2 as a worst case scenario example, which even in the worst case, the numbers are quite small.
The simple yet amazing wonders of the B-Tree are what keep me going day after day. Good morning!
@ypercubeᵀᴹ ...Though I just realized I was off even with just log2(n), the numbers are actually smaller even in the worst case not considering branching. 30, and 40 respectively. Thanks for drawing my attention to that, lol.
It kind of bugs me that they don't just come out and say which hint is persisted in QS for each of those items.
> CE Feedback can detect such scenarios and turn off the special row goal optimization. If it turns out that the query is indeed faster without this assumption, we keep this change by persisting it in the query store in the form of a query store hint, and the new optimization will be used for future executions of the query.
@PaulWhite I had that thought too. I read "In this blog, I will explain these model variants and what they mean in more detail." and then I looked at the scrollbar and was like "that's not nearly small enough."
but I suppose saying, if estimates are off, we'll try a few likely-looking but still petty conservative hints to see if things get better or not. You could do this yourself, but you're too dumb to understand...wouldn't go down well
My suspicions were aroused when it started off by talking about only having one CE model
Honestly, if people chose better keys (or actual keys, for that matter) a lot of these issues don't show up. I write some pretty bonkers stuff and the need to use hints almost never occurs. Disk/memory is almost always the limiting factor, not something the query engine is guessing wrong at.
That was an ambitious idea. Tweaking hints is not so ambitious.
@bbaird Yes, the CE model has its roots in the relational model. If you don't have a relational model (and most don't) you're relying on luck
A fair amount of the new stuff relies on people's natural expectation that newer things will also be better, through some mysterious (and undocumented) mechanisms
i feel like the only sensible future iteration of sql server has to be a tear down and rewrite to ditch all the backwards compatibility and reliance on un/semi-documented behavior
my no calls before 10am rule seems terrible when i have a call at 10am that i don't want to have before 11am
@PaulWhite I don't know anymore...Japan did everything to make me win zero points with their games....they won their first game against germany, then lost the second against Costa Rica, and ended winning again spain
> The 128-vCore compute size runs on Intel's Xeon Platinum 8370C and AMD's Epyc 7763v chipsets. With the new size, the databases and elastic pools deliver maximum input/output operations per second (IOPS) of 327,680 and 409,600 respectively. Microsoft says this is the highest of any Azure SQL compute size.
I have taken Robs method, and turned it into a function, and written a test script for it.
I can no longer find any mistakes.
CREATE or alter FUNCTION dbo.CalcAge
(
@DOB date, /* birthday */
@Today date /* either today or the day you want to calculate the age for */
)
RETURNS TABLE
AS
RETURN
...
weird
The performance issue in both queries has nothing to do with CTE vs. temp table. I see there is a timing difference, but hear me out a little bit.
just delete
In the straight delete, you spend the most time deleting from tables, not selecting from them.
The waits in this query are all rela...
inquiring minds!
someone should suspend their account until they answer
@ErikDarling people are strange sometimes. It does seem like there's missing context there, but I have no idea what it is. Perhaps there was an off-site interaction
It's a curious method though. Part of me is interested in why it works
@SeanGallardy You've been doing that a bit recently. Didn't HASHBYTES get the treatment for 2022?
@ErikDarling I'm running just audio so I think the i3 is probably going to be overkill, but $395 is about the cheapest I can find and cheaper than buying parts by themselves.
I suppose I could also try my NAS, but it's 6+ years old at this point.
Aw heck, this widdle 5i lenovo thingy is cuter and 30 bucks less