June 8, 2015 at 3:12 pm
Well here's a new slant on the 'partitioning for performance'...
Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 9, 2015 at 1:28 am
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Sounds cutting edge... where can I read such an article?
:unsure:
June 9, 2015 at 1:41 am
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Oh my, sounds like a perfect plan....for disaster, wonder what kind of "processing" this would be?
😎
BTW does this veering off entail wearing ones cloths the wrong way around?
June 9, 2015 at 2:48 am
BL0B_EATER (6/9/2015)
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Sounds cutting edge... where can I read such an article?
:unsure:
In the comments for my article yesterday.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 9, 2015 at 2:50 am
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Whenever I see "partitioning for performance" I go for my gun.
-- Gianluca Sartori
June 9, 2015 at 6:07 am
spaghettidba (6/9/2015)
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Whenever I see "partitioning for performance" I go for my gun.
In that case, could you give me a hand?
http://www.sqlservercentral.com/Forums/Topic1692297-1390-1.aspx
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 9, 2015 at 7:22 am
GilaMonster (6/9/2015)
spaghettidba (6/9/2015)
GilaMonster (6/8/2015)
Well here's a new slant on the 'partitioning for performance'...Switch the partitions that are needed out to a staging table, do processing on the staging table then switch the partitions back into the fact table.
What could possibly go wrong?
Whenever I see "partitioning for performance" I go for my gun.
In that case, could you give me a hand?
http://www.sqlservercentral.com/Forums/Topic1692297-1390-1.aspx
Thrown in my €0.02
-- Gianluca Sartori
June 9, 2015 at 9:19 am
Eirikur Eiriksson (6/4/2015)
Should be as simple as
..TOP(1)...
WHERE POST.VISIBLE = TRUE;
😎
Nothing is ever simple, and the queries that do this potentially slow way down with a check for banned users. We have probably banned thousands of users, and I'm not sure how well the data model or indexing would support this.
Banned users are not supposed to be able to log in, so there's a separate problem elsewhere.
June 9, 2015 at 9:20 am
Jeff Moden (6/4/2015)
Shifting gears a bit...Have any of you ever used a CTP of SQL Server to power your real production databases? Personally, I think such a thing would be insane.
It's not allowed by licensing unless you are in the TAP program with Microsoft. In that case, you get special support to help you.
I don't think it's insane. For the most part, much of SQL Server doesn't change between versions, so most things work. IF you are testing something new, like writeable columnstore indexes in 2014, or in this case, stretch to Azure, you have developers and staff that are working with the product, code, and issues on a regular basis, so you're prepared for potential problems.
June 9, 2015 at 9:26 am
Steve Jones - SSC Editor (6/9/2015)
Eirikur Eiriksson (6/4/2015)
Should be as simple as
..TOP(1)...
WHERE POST.VISIBLE = TRUE;
😎
Nothing is ever simple, and the queries that do this potentially slow way down with a check for banned users. We have probably banned thousands of users, and I'm not sure how well the data model or indexing would support this.
Banned users are not supposed to be able to log in, so there's a separate problem elsewhere.
There's a forum I use at work where some amazing people do seemingly impossible smoke and mirror stuff with slow queries..oh heck, where's the coffee
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 9, 2015 at 9:28 am
So tempted to whip out "DO YOU KNOW WHO I AM?"
Time to walk away from the forums for a few...
Where the **** is that tent?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2015 at 9:32 am
Grant Fritchey (6/9/2015)
So tempted to whip out "DO YOU KNOW WHO I AM?"Time to walk away from the forums for a few...
Where the **** is that tent?
Good lord Grant! You were Toni Braxton in a previous life?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
June 9, 2015 at 9:34 am
Grant Fritchey (6/9/2015)
So tempted to whip out "DO YOU KNOW WHO I AM?"Time to walk away from the forums for a few...
Where the **** is that tent?
Still in the desert, just look for the Guard Hippo, can't miss him in the bright pink tutu.
June 9, 2015 at 10:19 am
ChrisM@Work (6/9/2015)
Steve Jones - SSC Editor (6/9/2015)
Eirikur Eiriksson (6/4/2015)
Should be as simple as
..TOP(1)...
WHERE POST.VISIBLE = TRUE;
😎
Nothing is ever simple, and the queries that do this potentially slow way down with a check for banned users. We have probably banned thousands of users, and I'm not sure how well the data model or indexing would support this.
Banned users are not supposed to be able to log in, so there's a separate problem elsewhere.
There's a forum I use at work where some amazing people do seemingly impossible smoke and mirror stuff with slow queries..oh heck, where's the coffee
Would you be so kind Chris to share the URL:-D
😎
June 9, 2015 at 10:34 am
Steve Jones - SSC Editor (6/9/2015)
Eirikur Eiriksson (6/4/2015)
Should be as simple as
..TOP(1)...
WHERE POST.VISIBLE = TRUE;
😎
Nothing is ever simple, and the queries that do this potentially slow way down with a check for banned users. We have probably banned thousands of users, and I'm not sure how well the data model or indexing would support this.
Banned users are not supposed to be able to log in, so there's a separate problem elsewhere.
Complexity quickly mounts up and maybe the real point here is that one would neither optimize the system for handling exceptions like banned users nor for other such outlying cases, as you said, those should be handled higher up in the chain.
😎
Viewing 15 posts - 48,826 through 48,840 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply