Table Partitioning

Partitioned tables and indexes, elimination, boundaries, and tradeoffs.

26 associated posts22 primary posts

Office Hours: “Read This” Edition

Sometimes when people post questions at https://pollgab.com/room/brento, the answer is just a link, nothing more, nothing less. It doesn't make sense for me to rehash something that's been covered really well online, and I want to link 'em to the best resource possible. Petr: Huge slowdown of basic queries when using a partitioned table (Partition_Key…

Read more about Office Hours: “Read This” Edition 1 comment — Join the discussion

Partitioned Tables Cause Longer Plan Compilation Times.

Folks sometimes ask me, "When a table has more indexes, and SQL Server has more decisions to make, does that slow down execution plan generation?"

Well, maybe, but the table design choice that really screws you on compilation time is partitioning. If you choose to partition your tables, even tiny simple queries can cause dramatically higher CPU times. Even worse, as the famous philosopher once said, "Mo partitions, mo problems."

Read more about Partitioned Tables Cause Longer Plan Compilation Times. 12 comments — Join the discussion
T-SQL & Development

How to Create a Table with a Partitioned Clustered Columnstore Index

If you need to create a table and you want it to be partitioned right from the start, AND you want it to have a clustered columnstore index, here's a creation T-SQL example:
[crayon-6a6ef4f346b48054469357/]
The partition scheme name goes on the outside of the parenthesis, the index name goes on the inside, and the order of the whole thing is a little counter-intuitive.

Read more about How to Create a Table with a Partitioned Clustered Columnstore Index 8 comments — Join the discussion
Production DBA

DBA Training Plan 17: Should You Partition Your Tables?

In the last episode, I talked about knowing when it's time to scale out: identifying when our data is getting to be so large that we have to split it across multiple servers, and I explained why that is so challenging. But what about table partitioning - SQL Server's ability to break up a single table into smaller ones on the same server?

Read more about DBA Training Plan 17: Should You Partition Your Tables? 11 comments — Join the discussion

Index Tuning Week: Fixing Nonaligned Indexes On Partitioned Tables

Unquam Oblite
This post will not change your life, but it will help me remember something.

When you decide to partition a table to take advantage of data management features, because IT IS NOT A PERFORMANCE FEATURE, or you have an existing partitioned table that takes advantage of data management features, because IT IS NOT A PERFORMANCE FEATURE, you may have or end up with nonclustered indexes that aren't aligned with the partitioning scheme.

Read more about Index Tuning Week: Fixing Nonaligned Indexes On Partitioned Tables 19 comments — Join the discussion

How to Use Partitioning to Make kCura Relativity Faster

kCura Relativity is an e-discovery program used by law firms to find evidence quickly. I've blogged about performance tuning Relativity, and today I'm going to go a little deeper to explain why DBAs have to be aware of Relativity database contents.

In Relativity, every workspace (case) lives in its own SQL Server database. That one database houses:

Read more about How to Use Partitioning to Make kCura Relativity Faster 4 comments — Join the discussion
Performance Tuning

Filtered Indexes vs. Table Partitioning

It was a dark and stormy… Oh, wrong story. It was actually a warm, sunny afternoon in Charlotte, NC. I was presenting “Index Methods You’re Not Using” at PASS Summit. In this talk, I discussed how indexed views, filtered indexes, and compressed indexes can improve your query performance by reducing I/O.

From stage right, an intrepid audience member raised his hand and asked, “Can you think of an example of when you would use filtered indexes instead of partitioning?”

Read more about Filtered Indexes vs. Table Partitioning 7 comments — Join the discussion

Best Practices + Table Partitioning: Merging Boundary Points

One of the many best practices for SQL Server's table partitioning feature is to create "extra" empty partitions around your data. This is explained in SQL Server Books Online in the page on altering a Partition Function: Always keep empty partitions at both ends of the partition range to guarantee that the partition split (before…

Read more about Best Practices + Table Partitioning: Merging Boundary Points Be the first to comment