honestly - I don't know why but the combination of a good serving of cheese, and an early bedtime will give me some wickedly surreal dreams about 6-7 AM the next morning.
Doesn't matter what cheese, but if the alarm goes off earlier, the dreams don't happen or I don't rememeber them the same way
heh I do on-call one week in four, and I definitely need the get-up alarm come thursday/friday. Finish time is 2 AM and I have to be up by 7 AM to get to work for the day shift.
on the upside, its basically double-pay for that week, which is worth doing
Does anyone think it's a bit sad that skip-scanning is not implemented in SQL Server? At least for partitioned tables it should be pretty trivial dbfiddle.uk/vcVOBx9M
you'd think the interns would have so much more important work, like JSON functions and adding another concat method, rather than improving probably a huge chunk of all usages of ROW_NUMBER
which of those does actually prevent parallelism? Inline TVFS definitely not. Scalars for sure (depends on SCHEMABINDING I think). CLRs, both types, does it depend on the DataAccessKind value? what about the others?
non-inlineable scalar udfs make the query that calls them ineligible for a parallel plan, but the query within the function doesn't have that restriction
multi-statement table valued functions will get you a serial zone in the plan. i never state this to paul's exacting standards, but reading from the table variable returned by them is ineligible for parallelism. also query plans for modifying table variables are ineligible for parallelism.
inline table valued functions have no restrictions
for clr, it only depend on if they access data (like you mentioned). if they do, they're ineligible for parallelism.
It is well-known that SCHEMABINDING a function can avoid an unnecessary spool in update plans:
If you are using simple T-SQL UDFs that do not touch any tables (i.e. do not access data), make sure you specify the SCHEMABINDING option during creation of the UDFs. This will make the UDFs schema-...
You didn't assess Josh's frog. In his birthday month as well. Shame.
Partitioned objects can do a 'skip scan' already, but only at the partition level
I suppose one issue with generalised skip scan is ensure the optimiser doesn't go overboard with them. I think I was told once that it's just too hard to do and people should just columnstore and batch mode things instead.
It is well-known that SCHEMABINDING a function can avoid an unnecessary spool in update plans:
If you are using simple T-SQL UDFs that do not touch any tables (i.e. do not access data), make sure you specify the SCHEMABINDING option during creation of the UDFs. This will make the UDFs schema-...
