« first day (5035 days earlier)      last day (130 days later) » 

00:07
@J.D. people are surprisingly able to accept terrible conditions, historically
 
2 hours later…
02:00
@SeanGallardy giggity
@SeanGallardy It's insane.
@ErikReasonableRatesDarling Yet complain about performance simultaneously and look for NoSQL to save the day because SQL isn't built for "big data".
 
4 hours later…
05:38
Wordle 1,216 3/6*

⬛🟨⬛⬛⬛
🟩⬛🟩🟨⬛
🟩🟩🟩🟩🟩
06:19
Wordle 1,216 5/6*

⬛⬛⬛⬛⬛
⬛⬛🟨⬛⬛
⬛🟩⬛🟨⬛
⬛🟩⬛🟨🟩
🟩🟩🟩🟩🟩
07:00
Wordle 1,216 4/6*

⬛⬛⬛⬛🟩
⬛🟨⬛⬛🟩
🟨🟩⬛🟨🟩
🟩🟩🟩🟩🟩
@ErikReasonableRatesDarling Your "Ola Stats Only Job.sql" script has a comment in the header stating Targets the master database but in the code you USE msdb.
 
4 hours later…
11:20
I created an agent job in the gui and scripted it out. You should file an issue with Microsoft about that defect.
@ErikReasonableRatesDarling will do. Probably in 2026.
11:50
timely as ever
@PaulWhite have you ever been able to repro the data movement error with a nolock hint?
@ErikReasonableRatesDarling Not in recent times. They did stuff to make it a lot less likely
hm okay
look at microsoft
practically condoning nolock hints
postgres doesn't have this problem
12:06
well, the 'did stuff' involves giving up and moving to the next page so
and it's not like it's foolproof, just can't be bothered to try to repro these days
12:17
are there any prerequisites wrt table size/indexing that you recall
this isn't for the isolation levels presentation, just a minor curiosity
and as noted in KB815008 you may need to set the transaction isolation level instead of using a NOLOCK hint
I mention that because for a quick repro, people often rely on hints
all that said, most common cases have been 'addressed' coped with by now
u cot me
huh
this is not the plan shape i expected
SELECT
    d2.*
FROM dbo.do_it AS d
CROSS APPLY
(
    SELECT TOP (1)
        *,
        wtf = dbo.wait_for(d2.wait_for)
    FROM dbo.do_it AS d2
    WHERE d.id = d2.id
) AS d2;
i figured the compute scalar would be in the outer part of the nlj
interesting
make it non-deterministic?
anyway
> Performing a select statement on a database that exists on a CD-ROM disc may return the following error:

Error: 601, Severity: 12, State: 2
Could not continue scan with NOLOCK due to data movement.
> APPLIES TO Microsoft SQL Server 7.0 Standard Edition, when used with:
Microsoft Windows NT 4.0; Microsoft SQL Server 2000 Standard Edition
More SE problems
coming soon to azure: PREEMPTIVE_CDROM_REQUEST waits
no one needs that much I/O perf
12:54
the function is non-deterministic, according to sql server. also not precise.
ah well
@ErikReasonableRatesDarling try TF 9259 if you're curious enough
i am. what does that do?
stops compute scalars moving around so much
> FIX: Performance is significantly reduced when you set trace flag 9134 to prevent error message 601 in SQL Server 2000
🤣
no change in the plan with it as a querytraceon or globally enabled
this compute scalar is a real damn barnacle
ah well
13:03
8 mins ago, by Erik Reasonable Rates Darling
ah well
I might be interested enough to look into it if you provide a low-effort repro
but yeah that happens
that's about as low effort as i can make it
thx
@ErikReasonableRatesDarling seems to fail with an error
any specific error
> Msg 4121, Level 16, State 1
Cannot find either column "dbo" or the user-defined function or aggregate "dbo.wait_for", or the name is ambiguous.
13:15
did you get the function in the gist?
God I h8 gist
if you don't see it hit refresh, it's just below the first file
thx again
have it now
@PaulWhite It's intimidating at first but then you'll get the gist of it
13:53
What's the new thing with the asterisk next to the number of close votes on questions?
Oct 9 at 14:36, by Erik Reasonable Rates Darling
oh you get a little asterisk by the close link now if you've already voted to close something
this gets the computer scalar before the join, but uses a merge join which is annoying
SELECT
    d.*
FROM dbo.do_it AS d
WHERE EXISTS
(
    SELECT
        1/0
    FROM dbo.do_it AS d2
    WHERE d.id = d2.id
    AND d.wait_for = dbo.wait_for(d2.wait_for)
);
if i use the function on both columns, it's still a merge join and both functions are evaluated at the join
14:09
@ErikReasonableRatesDarling What is it you'd like to achieve? CS before join or under top? Try an outer apply
@J.D. because your CIO can blame someone else when that turd sandwich promised doesn't taste very good.
Which is a pretty shitty reason if you ask me
@ErikReasonableRatesDarling Or try this:
SELECT
    d2.*
FROM dbo.do_it AS d
CROSS APPLY
(
    SELECT TOP (1)
        *,
        wtf = dbo.wait_for(d2.wait_for)
    FROM dbo.do_it AS d2
    WHERE d.id = d2.id
    ORDER BY
        wtf
) AS d2;
@Zikato Ho ho. Yeah, I just meant sharing code via gists is tedious and infuriating. Easy to miss supplemental scripts as I did and there's no really easy way to copy code to the clipboard.
14:57
@PaulWhite that's maddening, but ty
15:26
@HannahVernon yea sounds like something a shitty CIO would do lol
 
1 hour later…
16:51
> Msg 601, Level 12, State 3, Line 8
Could not continue scan with NOLOCK due to data movement.
@ErikReasonableRatesDarling repro'd on 2022 ^
@PaulWhite did you use the example from craig's post or did you need something more involved?
@ErikReasonableRatesDarling I think he says in the post that example was fixed in 2005
I created a new one
17:07
groovy
i was going to try to write one where the scalar udf slowed down reads and writes
but mostly because i couldn't think of a very clever use for the function as a performance problem
perhaps i'll use it as a thought experiment
But you're The Flash
17:20
Only in that session
18:19
Thank you, Erik. I thought that this was simple, but merely reading the blogs was not enough. Once I studied them, the revelation blew me off of my chair. Your posts are like being covered in jet fuel. — J. Mini 55 mins ago
did i do 9/11?

« first day (5035 days earlier)      last day (130 days later) »