Craig Freedman's SQL Server Blog : Partitioned Tables

Dynamic Partition Elimination Performance

craigfr — Sat, 23 Aug 2008 01:42:00 GMT

In this post on partitioned tables, I mentioned that SQL Server 2008 has a much more efficient implementation of dynamic partition elimination as compared to SQL Server 2005. In response, a reader posted this comment asking how much dynamic partition elimination really costs in SQL Server 2005. While I was sure that the answer is not much, I nonetheless decided to measure it and find out.

I wrote the following stored procedure which creates a table with the specified number of partitions:

CREATE PROCEDURE CreateTable @N INT
AS
BEGIN
    DECLARE @Cmd VARCHAR(8000)
    DECLARE @I INT

    SET @Cmd = 'CREATE PARTITION FUNCTION PF(INT) AS RANGE FOR VALUES (1'

    SET @I = 2
    WHILE @I < @N
        BEGIN
            SET @Cmd = @Cmd + ',' + CONVERT(VARCHAR(4),@I)
            SET @I = @I + 1
        END

    SET @Cmd = @Cmd + ')'

    EXECUTE (@Cmd)

    CREATE PARTITION SCHEME PS AS PARTITION PF ALL TO ([PRIMARY])

    CREATE TABLE T1 (A INT, B INT)
    CREATE CLUSTERED INDEX T1A ON T1(A) ON PS(A)
END

I then created a table with either 2, 10, 100, or 1000 partitions. For each table, I ran the following batch:

SET NOCOUNT ON

DECLARE @T DATETIME
DECLARE @I INT, @J INT, @K INT
SET @I = 0
SET @J = 0
SET @T = GETDATE()
WHILE @J < 10000
    BEGIN
        SELECT @K = B FROM T1 WHERE A < @I
        SET @J = @J + 1
    END
SELECT DATEDIFF (MS, @T, GETDATE())

The main SELECT statement in this batch scans a single partition but, because the WHERE clause references a variable, SQL Server does not know this information at compile time. This query is too fast to measure a single execution accurately. Thus, I magnify the cost by repeating the query 10,000 times in a WHILE loop. The SET NOCOUNT ON statement and the assignment in the SELECT statement merely serve to minimize client communication costs which would otherwise dominate the batch cost.

The table is empty which makes this test a worst case scenario. The cost of the query is dominated by the cost of locating the correct partition.

Looking at the SQL Server 2005 STATISTICS PROFILE output for the 1000 partition table, we can see that SQL Server tests each partition before scanning only the one that is not eliminated:

0      1        |--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
1      1             |--Filter(WHERE:([PtnIds1004]<=RangePartitionNew([@I],(0),(1),(2),(3),...
1000   1             |    |--Constant Scan(VALUES:(((1)),((2)),((3)),...
0      1             |--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([T1].[A] < [@I]) ORDERED FORWARD PARTITION ID:([PtnIds1004]))

By comparison, SQL Server 2008 seeks directly to the correct partition:

0      1        |--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([PtnId1000] >= (1) AND [PtnId1000] <= RangePartitionNew([@I],(0),(1),(2),(3),...

Here are the results. In each case, before collecting any data, I ran the batch once to eliminate compilation overhead and warm up costs. I then took the median of 5 runs. Times are in milliseconds for the full 10,000 executions of the query. Note that we cannot compare the SQL Server 2005 results directly to the SQL Server 2008 results as I ran these tests on two different machines. However, the relative cost of adding partitions in SQL Server 2005 vs. SQL Server 2008 is clear.

# Partitions	SQL Server 2005	SQL Server 2008
2	233	216
10	313	203
100	1216	216
1000	18060	216

It is important to remember that these are times for 10,000 executions of the query. Thus, even on SQL Server 2005 with 1000 partitions, the cost of a single execution of the query is only 1.8 milliseconds. Moreover, if the table contains any real data and if the query returns even a modest number of rows, the cost of the query will be dominated by the actual data processing.

Partitioned Indexes in SQL Server 2008

craigfr — Tue, 05 Aug 2008 21:33:00 GMT

In my last post, I looked at how SQL Server 2008 handles scans on partitioned tables. I explained that SQL Server 2008 treats partitioned tables as tables with a logical index on the partition id column and that SQL Server 2008 implements partition elimination by performing a logical index seek on the partition id column. Specifically, I showed some examples using a heap. In this post, I'll continue this discussion and explore how SQL Server 2008 handles scans and seek on partitioned indexes.

Let's begin with a simple example:

CREATE PARTITION FUNCTION PF(INT) AS RANGE FOR VALUES (0, 10, 100)
CREATE PARTITION SCHEME PS AS PARTITION PF ALL TO ([PRIMARY])

CREATE TABLE T1 (A INT, B INT)
CREATE CLUSTERED INDEX T1A ON T1(A) ON PS(A)

As I noted in my last post, the SQL Server query processor logically treats this partitioned index as a multi-column index on ([PtnId], A). We can scan this logical index just like any real index:

SELECT * FROM T1

|--Clustered Index Scan(OBJECT:([T1].[T1A]))

This query uses the same plan as any other clustered index scan. It implicitly scans all of the partitions. Aside from the "Partitioned" attribute in the graphical and XML plans, there is no difference between this plan and a similar clustered index scan on a non-partitioned table. We can also perform a seek on the logical index:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T1 WHERE A = @I

|--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([PtnId1000]=RangePartitionNew([@I],(0),(0),(10),(100)) AND [T1].[A]=[@I]) ORDERED FORWARD)

Notice that SQL Server derives the predicate on the [PtnId] column from the explicit predicate on column A. SQL Server then seeks on both columns of the logical index - [PtnId] and column A - just as if the logical index were a real index. So far, everything is pretty straightforward. Now, let's consider a slightly more complex scenario:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T1 WHERE A < @I

Both this and the prior example have predicates on column A. In both cases, SQL Server derives a predicate on the [PtnId] column. However, in the prior example, the derived predicate was an equality predicate that limited the seek to a single partition. In this example, due to the inequality, the derived predicate is actually a range of partitions:

|--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([PtnId1000] >= (1) AND [PtnId1000] <= RangePartitionNew([@I],(0),(0),(10),(100)) AND [T1].[A] < [@I]) ORDERED FORWARD)

If you are familiar with the rules on index seeks, you will notice something odd about this plan. Ordinarily, SQL Server can only perform an index seek on the second column of a multi-column index if there exists an equality predicate on the first column. Clearly, there is not an equality predicate on the [PtnId] column in this query and yet there is a predicate on column A. What's going on? The query processor supports a special type of index seek on partitioned tables. Basically, the query processor first uses the predicate on the [PtnId] column to identify those partitions into which to seek and then seeks again using the predicate on column A. Because the seek operator skips over some rows in each partition that do not match the predicate on column A, we refer to this type of seek as a skip scan. Note that this operation really is a seek - it is not a residual predicate. The storage engine only returns those rows that pass both predicates. Also note that SQL Server 2008 only supports this skip scan functionality on the [PtnId] column of a partitioned table.

Now let's change the schema slightly:

CREATE TABLE T2 (A INT, B INT)
CREATE CLUSTERED INDEX T2A ON T2(A) ON PS(B)

This new table is indexed on column A but partitioned on column B. Once again, SQL Server logically treats the index as a multi-column index on ([PtnId], B).

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T2 WHERE A = @I

Since the table is partitioned on column B, we cannot use the predicate on column A to derive a predicate on the [PtnId] column. Fortunately, the query processor can still perform a skip scan by adding a predicate on the [PtnId] column that explicitly scans all partitions:

|--Clustered Index Seek(OBJECT:([T2].[T2A]), SEEK:([PtnId1000] >= (1) AND [PtnId1000] <= (4) AND [T2].[A]=[@I]) ORDERED FORWARD)

Finally, before I wrap up this post, I'd like to point out that, while it's not often useful, we can add an explicit predicate on the [PtnId] column of a table. To do so, we use the $PARTITION function:

DECLARE @PtnId INT
SELECT @PtnId = 1
SELECT * FROM T1 WHERE $PARTITION.PF(A) = @PtnId

|--Clustered Index Scan(OBJECT:([T1].[T1A]), SEEK:([PtnId1000]=[@PtnId]) ORDERED FORWARD)

Just as with the derived [PtnId] predicates, SQL Server can perform a seek on the [PtnId] column. When using this syntax, it is important to use the correct $PARTITION function and the correct column or SQL Server will not recognize it as the [PtnId] column for this table.

Books Online has more information on these and other partitioned table changes in SQL Server 2008.

Partitioned Tables in SQL Server 2008

craigfr — Wed, 16 Jul 2008 00:03:00 GMT

In this post, I introduced how SQL Server 2005 implements query plans on partitioned tables. If you've read that post or used partitioned tables, you may recall that SQL Server 2005 uses a constant scan operator to enumerate the list of partition ids that need to be scanned. As a refresher, here is the example from that post showing the plan for scanning a table with four partitions:

CREATE PARTITION FUNCTION PF(INT) AS RANGE FOR VALUES (0, 10, 100)
CREATE PARTITION SCHEME PS AS PARTITION PF ALL TO ([PRIMARY])
CREATE TABLE T (A INT, B INT) ON PS(A)

SELECT * FROM T

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
|--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
|--Table Scan(OBJECT:([t]))

SQL Server 2005 treats partitioned tables specially and creates special plans, such as the above one, for partitioned tables. SQL Server 2008, on the other hand, for the most part treats partitioned tables as regular tables that just happen to be logically indexed on the partition id column. For example, for the purposes or query optimization and query execution, SQL Server 2008 treats the above table not as a heap but as an index on [PtnId]. If we create a partitioned index (clustered or non-clustered), SQL Server 2008 logically adds the partition id column as the first column of the index. For instance, if we create the following index:

CREATE INDEX TA ON T(A) ON PS(A)

SQL Server 2008 treats it not as a single column index on T(A), but rather as a multi-column or composite index on T([PtnId],A). Note that the table and index are still stored physically as partitioned tables. In this example, the table and non-clustered index are decomposed into four heaps and four non-clustered indexes.

By treating partitioned tables as indexes, SQL Server 2008 can frequently use much simpler query plans. Let's look at the SQL Server 2008 plan for the above example:

|--Table Scan(OBJECT:([T]))

This query plan is no different than what you might see if you scanned any other ordinary table! So, how can we tell that the table is really partitioned and how can we tell what partitions the plan is going to scan? Luckily, the graphical and XML plans identify partitioned tables by adding a "Partitioned" attribute to any scan, seek, or update operator that processes a partitioned table. Moreover, the actual graphical plan and the STATISTICS XML output identify the exact partitions that the plan touches during execution. For example, here is an excerpt from the STATISTICS XML output generated by running the above query:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="4">
<PartitionRange Start="1" End="4"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

This output shows that, as expected, the query plan scanned all four partitions of the table. Now, suppose we insert a row into the second partition (up until now, the table has been empty) and run the following slightly modified query:

INSERT T VALUES (1, 1)

SELECT TOP 1 * FROM T

This query can stop executing as soon as it finds a single row. It scans the first partition and finding no rows continues on to scan the second partition. At that point, it finds a row and stops. Thus, the query terminates after scanning only two partitions. This outcome is clearly reflected in the STATISTICS XML output:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="2">
<PartitionRange Start="1" End="2"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

Now let's see how partition elimination works. Let's start with static partition elimination:

SELECT * FROM T WHERE A < 100

|--Table Scan(OBJECT:([T]), SEEK:([PtnId1001] >= (1) AND [PtnId1001] <= (3)), WHERE:([T].[A]<(100)) ORDERED FORWARD)

Because SQL Server 2008 treats the partitioned table like an index on [PtnId], it can simply calculate the range of partitions that need to be scanned and perform a "seek" on those partitions. It may seem a little strange to see a SEEK predicate on a table scan, but it just means that the plan is going to scan partitions 1 through 3.

And now, let's look at dynamic partition elimination:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T WHERE A < @I

|--Table Scan(OBJECT:([T]), SEEK:([PtnId1001] >= (1) AND [PtnId1001] <= RangePartitionNew([@I],(0),(0),(10),(100))), WHERE:([T].[A]<[@I]) ORDERED FORWARD)

This plan is identical to the prior plan except that the constant partition id 3 has been replaced by the RangePartitionNew function which computes the correct partition id from the variable @I. To find out exactly which partitions were scanned, we can once again check the STATISTICS XML output:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="1">
<PartitionRange Start="1" End="1"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

Note that this plan computes exactly which partitions to scan. Compare that to the SQL Server 2005 plan which evaluates a filter for each and every partition id:

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
       |--Filter(WHERE:([PtnIds1004]<=RangePartitionNew([@i],(0),(0),(10),(100))))
       |    |--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
       |--Table Scan(OBJECT:([t]), WHERE:([t].[a]<[@i]) PARTITION ID:([PtnIds1004]))

While evaluating the filter repeatedly may not cost too much if we have only four partitions, it is certainly going to waste some cycles if we have many partitions!

In my next post, I'll take a look at how SQL Server 2008 handles scans and seeks on partitioned indexes.

Introduction to Partitioned Tables

craigfr — Mon, 27 Nov 2006 22:56:00 GMT

In this post, I’m going to take a look at how query plans involving partitioned tables work. Note that there is a big difference between partitioned tables (available only in SQL Server 2005) and partitioned views (available both in SQL Server 2000 and in SQL Server 2005). I will look at the query plans for partitioned views in a future post.

Table Scan

Let’s begin by creating a simple partitioned table:

create partition function pf(int) as range for values (0, 10, 100)

create partition scheme ps as partition pf all to ([primary])

create table t (a int, b int) on ps(a)

This creates a table with four partitions. SQL Server assigns sequential partition ids to each of the four partitions as follows:

PtnId	Values
1	t.a <= 0
2	0 < t.a <= 10
3	10 < t.a <= 100
4	100 < t.a

Now let’s examine the query plan for a simple table scan:

select * from t

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
|--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
|--Table Scan(OBJECT:([t]))

SQL Server explicitly enumerates the partition ids that the table scan must touch using the constant scan and nested loops join operators. Recall that a nested loops join executes its second or inner input (in this case the table scan) once for each value from its first or outer input (in this case the constant scan). Thus, we run the table scan four times; once for each partition id.

Note also that the nested loops join explicitly identifies the partition id column as [PtnIds1004]. Although it is not immediately obvious from the text showplan (unfortunately, we omit this information in some though not all cases), the table scan uses the partition id column and checks it on each execution to determine which partition to scan. This information is always available in the graphical showplan (via the table scan tool tip and properties) and in the XML showplan:

...

</PartitionId>

</TableScan>

Static Partition Elimination

Consider the following query:

select * from t where a < 100

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1005]) PARTITION ID:([PtnIds1005]))
|--Constant Scan(VALUES:(((1)),((2)),((3))))
|--Table Scan(OBJECT:([t]), WHERE:([t].[a]<(100)) PARTITION ID:([PtnIds1005]))

The predicate “a < 100” clearly eliminates all rows from partition id 4. There is no point in scanning this partition as none of the rows in this partition can possibly qualify for the predicate. The optimizer recognizes this fact and eliminates that partition from the plan. The constant scan now enumerates only three partitions. We refer to this as “static partition elimination” because we know the exact list of partitions to scan statically at compile time.

If we can statically eliminate all but one partition, we do not need the constant scan or join at all:

select * from t where a < 0

|--Table Scan(OBJECT:([t]), WHERE:([t].[a]<(0)) PARTITION ID:((1)))

Note that the exact partition id that we must scan (partition id 1) is now part of the table scan itself.

Dynamic Partition Elimination

In some cases, even though it is not possible for SQL Server to determine statically at compile time which partitions need to be scanned, the optimizer may be able to determine that some partition elimination is still possible.

declare @i int

select @i = 0

select * from t where a < @i

The above query is parameterized. Since we do not get the actual parameter value until run time (that I’ve provided a constant value for the parameter in the batch does not change things), there is no way to determine at compile time which partition ids to scan. We may scan just partition id 1, or we might scan partition ids 1 and 2, and so forth. Thus, the constant scan enumerates all four partition ids and we use a filter to eliminate partitions ids at run time. We refer to this as “dynamic partition elimination.”

The filter compares each partition id to the results of a special function “RangePartitionNew.” This function computes the results of applying the partition function to the parameter value. The arguments to this function (in left to right order) are: the value (in this case the parameter @i) that we want to map to a partition id, a Boolean flag that indicates whether the partition function maps boundary values to the left (0) or right (1), and the actual partition boundary values (in this case 0, 10, and 100).

In this example, since @i has the value 0, the result of RangePartitionNew is 1. Thus, we scan only partition id 1. Note that unlike the static partition elimination example, even though we scan only a single partition, we still have the constant scan and join. Again, we need these operators since we do not know how many partitions we will scan until run time.

In some cases, the optimizer can determine at compile time that we will scan only one partition even though it cannot determine which partition. For example, if we have an equality predicate on the partition key, we know that only partition can match. In this case, even though we have dynamic partition elimination, we do not need the constant scan and join. For example:

declare @i int

select @i = 0

select * from t where a = @i

|--Table Scan(OBJECT:([t]), WHERE:([t].[a]=[@i]) PARTITION ID:(RangePartitionNew([@i],(0),(0),(10),(100))))

Combining Static and Dynamic Partition Elimination

SQL Server can combine static and dynamic partition elimination in a single query plan:

declare @i int

select @i = 0

select * from t where a > 0 and a < @i

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
       |--Filter(WHERE:([PtnIds1004]<=RangePartitionNew([@i],(0),(0),(10),(100))))
       |    |--Constant Scan(VALUES:(((2)),((3)),((4))))
       |--Table Scan(OBJECT:([t]), WHERE:([t].[a]<[@i] AND [t].[a]>(0)) PARTITION ID:([PtnIds1004]))

Note that we statically eliminated partition id 1 from the constant scan and we may dynamically eliminate additional partition ids via a filter.

$partition

You can explicitly invoke the RangePartitionNew function using $partition:

select *, $partition.pf(a) from t

|--Compute Scalar(DEFINE:([Expr1004]=RangePartitionNew([t].[a],(0),(0),(10),(100))))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1005]) PARTITION ID:([PtnIds1005]))
            |--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
            |--Table Scan(OBJECT:([t]))

This query plan is identical to the table scan plan above except that we compute and output the partition id for each row.

For More Information

This post from the SQL Server Development Customer Advisory Team blog includes more partition elimination examples. The post includes some examples of where partition elimination does not work if you have predicates with disjunctions and parameters (such as “a > 0 or a < @i”) and some workarounds. One of the workarounds is to use a “union all” statement to eliminate the disjunction. If you use this workaround, beware that you must be sure that the or’ed predicates will not overlap and return duplicates. In some cases, a duplicate eliminating union (be sure to include a unique key in the select list) may be safer.