So, we need to know about partition functions, and how they are represented in meta-data. We have three tables to look at, [sys].[partition_functions] which gives us information about the partition functions themselves, [sys].[partition_parameters] which gives us information about the parameter(s) to a partition function, and [sys].[partition_range_values] which tells us the actual boundary values for a partition function.
name | The name of the partition function, which must be unique. |
|---|---|
function_id | The unique ID of the partition function. This is the function_id referred to in [sys].[partition_schemes]. |
type | This is the type code of the partition function, which can currently only be 'R' for a RANGE partition. If I was a betting man, I would bet on this being the only available option for a good few years. |
type_desc | This is the description that relates to the value in the type column. |
fanout | This is the number of partitions that result from the partition function. This one is a future compatibility option, seeing as the partition count is always the count of boundaries + 1 for a RANGE partition. |
boundary_value_on_right | This column is 1 if the boundary values themselves are placed on the right or left partition. For example, consider a range partition with boundaries 10, 20 and 30. So you get four partitions. Does 10 go into the first or the second partition? For a RANGE LEFT partition, it goes into the first, and for a RANGE RIGHT partition, it goes into the second, and in the latter case, this column shows a 1. |
create_date | This is the date on which the partition function was created. |
modify_date | This is the date on which the partition function was last altered. |
We get what looks like a good bit of information there, but, in effect, only tells us whether the partition function is a RANGE LEFT or a RANGE RIGHT function.
So, what about [sys].[partition_parameters]? What we get here is unsurprisingly very similar to the column and parameter metadata, so I have copied my descriptions from that post here:
function_id | This is the ID of the partition function that the parameter is for. |
|---|---|
parameter_id | This is the ID of the parameter. As for normal parameters, it is 1 based, and you would not expect to see any gaps. However, currently, you definitely won't see any gaps, as you can only have 1 parameter to RANGE partition functions - which are the only supported type. |
system_type_id | This column relates the column or parameter to [sys].[types]. However, this column tells you the class of data, rather than the exact type. So, if a user defined data type 'myBigInteger' is based on a bigint, then this is the column that tells you that the data in question is a bigint. |
max_length | This column, you might think, is the maximum length of the column. It's not. It's the storage space that's used. So for a [text] column, you'll see 16, even though the maximum length of the data that can be stored in the text type is a byte under 2GB. (MAX) and [xml] data types are the exception here - you'll see -1 in the [max_length] column for those. And a word of warning about nchar and nvarchar types - here you will see double the number declared as the data length, because those types take 2 bytes per stored character. |
precision | Precision is useful for numeric types. You will see values for other types, but they don't bear a lot of relevance. For example, do you really need to look at meta-data to know how many digits a 32-bit integer would store? However, for numeric types (i.e. numeric & decimal) the precision column is genuinely useful, as it tells you information that you need to know in order to determine how the data is defined, how it would be scripted and how the system will treat it. This you would not know without looking at the metadata. |
scale | Scale again is useful for numeric types. Exactly the same applies as for precision, you will see values for other types. |
collation_name | This is the name of the collation that the column is declared with, if the column is a character data type. Note that this is a [sys].[columns] only column because collation does not, and cannot, apply to parameters. |
user_type_id | This column again relates the column or parameter to [sys].[types]. This column does tell you the exact type of the data, and allows you to derive the exact type name for the column or parameter. |
A note on precision and scale, again copied from my previous post on columns and parameters - precision and scale are possibly the most misleading column names ever. You would think that precision would determine how precise a number was, and that scale would determine how big it could be. This leads to a common misconception that precision is the number of digits after the decimal point, and scale is the number of digits before the decimal point. It is actually the case that precision determines how many digits there are, and scale determines the number of digits to the right of the decimal point. In a way, the names do apply, but really I think total_digits and decimal_places would have been far more sensible in terms of column names.
We now know the partition functions name, range boundary application and parameter type, basically. So the only thing left to explore is boundary values - exposed in the cunningly named [sys].[partition_range_values]:
function_id | This is the ID of the partition function that the boundary value is for. |
|---|---|
boundary_id | This is the ID of the boundary, starting at 1, again with no gaps. This order is based on the natural ordering of the data type that the partition scheme parameter operates on. If you create an out-of-order partition scheme, the boundary values are sorted, and you get a warning. |
parameter_id | This is the ID of the parameter in [sys].[partition_parameters]. Seeing as the only supported type can only have 1 parameter, this column is effectively useless at the moment. In the future - who knows? |
value | This is the actual value of the boundary. The column is a sql_variant so it's type varies according to the type of the parameter. |
Excellent - we now have a complete knowledge of the storage subsystem, and using this data can confidently predict what destination filegroup a particular value in a partitioned table would be sent to, in code.
Next time we'll look at indexes, in their four different flavours.