> Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?
LOL, you're making the same mistake they did. thinking "index" means "too much time spent fetching the rows". read again - it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.
> Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out.
It wasn't just claude's idea, it was my idea too, the claude topic was that it would write a suite that proves the problem, in this case, very loud logging messages that were occurring for the customer when this quasi-deadlock situation occurred. it was not subtle.
> In this case, it sounds like you could have made a ten line repro that shows the problem.
no, it involved running a galera server and about four other services with a specific set of data conditions, again, read what I wrote, creating a proof of concept suite was not trivial to do by hand.
But why would you have to make the succinct suite by hand? Not what I was suggesting, I have gotten in the habit of sending extremely concise, human readable repro scripts made by Claude.
Partially because I can read and validate it actually shows what it claims to show, and partially because I expect people want to know what I’m telling them.
LOL, you're making the same mistake they did. thinking "index" means "too much time spent fetching the rows". read again - it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.
> Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out.
It wasn't just claude's idea, it was my idea too, the claude topic was that it would write a suite that proves the problem, in this case, very loud logging messages that were occurring for the customer when this quasi-deadlock situation occurred. it was not subtle.
> In this case, it sounds like you could have made a ten line repro that shows the problem.
no, it involved running a galera server and about four other services with a specific set of data conditions, again, read what I wrote, creating a proof of concept suite was not trivial to do by hand.
Partially because I can read and validate it actually shows what it claims to show, and partially because I expect people want to know what I’m telling them.
You’d think they’d have found this issue out before now; if there’s no usable index for the predicate, non-locking reads would’ve also been slow.
Also, I look forward to the next update wherein your colleagues create an index, and then discover the joys of gap locking under REPEATABLE-READ.